Hi,
On 9/2/26 4:00 PM, Bobby Eshleman wrote:
> From: Bobby Eshleman <[email protected]>
>
> 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 <[email protected]>
> Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/
> Signed-off-by: Bobby Eshleman <[email protected]>
> ---
> 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
