Re: [PATCH net-next 2/6] vsock: add IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS

[Randy Dunlap]

Hi,

On 9/2/26 4:00 PM, Bobby Eshleman wrote:
> From: Bobby Eshleman <bobbyeshleman@xxxxxxxx>
> 
> Namespaces let a host isolate a VM's vsock traffic to a specific
> namespace, but in a guest vsock traffic cannot be isolated to a
> namespace. The vsock device is hardcoded to global mode and can't be
> moved into a local-mode namespace.
> 
> Introduce ioctl IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS on /dev/vsock that
> gives userspace a way to move the device to the calling pid's namespace.
> The call requires CAP_NET_ADMIN in the root user namespace. A privileged
> user wishing to "unassign" the device can move it to the init_netns,
> which is hardcoded to global mode (so no unassign call is necessary).
> 
> A getter to read the current assignment back was considered, returning
> either the namespace's net_cookie or its nsfs inode number, but neither
> seemed useful enough to bake into the uAPI now. It can be added later if
> a user turns up that needs it.
> 
> Add a transport hook to indicate support for guest namespacing, so that
> transports may opt in/out. A transport that opts out keeps the
> reachability rules it had before this ioctl existed.
> 
> Sockets are reset when the underlying device moves to a different
> namespace, so as to prevent reachability from the previous and now
> disallowed namespace.
> 
> Following the approach of netdevs, the device returns to init_net when

I'm confused by the use of "init_net" several times and "init_netns" at
least 2 times. "init_net" is the initial, boot-time net namespace.

And is one of these what is referred to in the Documentation/ file below
as "initial namespace"?

> its namespace is removed. Care is taken to not break flows when the
> device is inside a global namespace that is being torn down and alive
> sockets are in a different global namespace. In this scenario, the
> device's netns getter pre-emptively falls back to the init_net (always
> global) so that these flows are not disrupted. If init_netns ever

                                           maybe    init_netns()
if you are referring to a function...

> supports local-mode in the future, this logic will have to be changed.
> 
> Suggested-by: Stefano Garzarella <sgarzare@xxxxxxxxxx>
> Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/
> Signed-off-by: Bobby Eshleman <bobbyeshleman@xxxxxxxx>
> ---
>  Documentation/admin-guide/sysctl/net.rst |  18 +++
>  include/net/af_vsock.h                   |   7 ++
>  include/uapi/linux/vm_sockets.h          |   6 +
>  net/vmw_vsock/af_vsock.c                 | 198 ++++++++++++++++++++++++++++++-
>  4 files changed, 228 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
> index e586e17fc7a5..1e9c0d2be7b8 100644
> --- a/Documentation/admin-guide/sysctl/net.rst
> +++ b/Documentation/admin-guide/sysctl/net.rst
> @@ -515,6 +515,24 @@ their hosts. The behavior of VSOCK sockets in a network namespace is determined
>  by the namespace's mode (``global`` or ``local``), which controls how CIDs
>  (Context IDs) are allocated and how sockets interact across namespaces.
>  
> +In a guest, the vsock device owned by the guest-to-host (G2H) transport belongs
> +to one network namespace at a time. The ``IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS``
> +ioctl on ``/dev/vsock`` moves it to the namespace of the calling process, which
> +requires ``CAP_NET_ADMIN`` in the initial user namespace. The namespace's mode

                              Is this the caller's namespace?

> +decides who may then use the device:
> +
> +- ``global`` - every ``global`` mode namespace may use it.
> +- ``local`` - only that namespace may use it, which reserves the connection to
> +  the host for it alone.
> +
> +The device starts out in the initial namespace, so until the ioctl is issued
> +nothing has moved and no mode has changed.
> +
> +Connections made before the move, from a namespace that can no longer reach the
> +device, are reset. The device returns to the initial namespace when the
> +namespace it was moved to is deleted, so assigning it to the initial namespace
> +is how an assignment is undone.
> +
>  ns_mode
>  -------
>  
thanks.
-- 
~Randy