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

[Pavel Tikhomirov]

> 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.

> 
> 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.

> +	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.

-- 
Pavel Tikhomirov <ptikhomirov at virtuozzo.com>