[Devel] [PATCH hci-8.1 v2 2/4] ve: Introduce override_ve/revert_ve helpers

[Vladimir Riabchun]

On 10/28/26 12:58, Pavel Tikhomirov wrote:
>> These helpers mirror override_creds/revert_creds and are supposed to
>> be used together in cases when VE creds may be stored and later used
>> by the different VE task.
> 
> In multiple places like /proc/<pid>/status task will jump to other VE.
> 
> Also anything using get_task_ve will be tricked to believe in task VE
> change. E.g.:
> 
> Small information leak, drivers/connector/cn_proc.c:209.
> proc_event_connector() sends events about a task to that task's VE's
> listeners.
> 

Agree. I'll instead introduce a separate field in task struct,
which will contain ve override, and will be used by ve_capable only.

>>
>> https://virtuozzo.atlassian.net/browse/VSTOR-142405
>> Signed-off-by: Vladimir Riabchun <vladimir.riabchun at virtuozzo.com>
>>
>> diff --git a/include/linux/ve.h b/include/linux/ve.h
>> index 717567775f58e..9d633717a7fe2 100644
>> --- a/include/linux/ve.h
>> +++ b/include/linux/ve.h
>> @@ -295,6 +295,23 @@ static inline struct vdso_image *ve_get_vdso_64(struct ve_struct *ve)
>>   	return ve->vdso_64;
>>   }
>>   
>> +static inline struct ve_struct *override_ve(struct ve_struct *new_ve)
>> +{
>> +	struct ve_struct *old_ve;
>> +
>> +	guard(task_lock)(current);
> 
> This adds a lock to hot paths such as ovl_permission, ovl_getattr and
> ovl_lookup; AI deems this worth stating, probably not that critical,
> but the save check result approach has no such problem.

Adding a separate field for overrides will solve this problem.
Nobody should race on it.

> 
>> +	old_ve = current->task_ve;
>> +
>> +	current->task_ve = new_ve;
>> +	return old_ve;
>> +}
> 
> What about direction checks? ve0->veX ok and veX->ve0 is probably a
> security breach and should not be allowed.

I'll add a guard against it. If current is a CT process, it shouldn't be
able to override VE, only ve0 -> veX is OK.

> 

-- 
Best regards, Riabchun Vladimir
Linux Kernel Developer, Virtuozzo