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

On Wed, Sep 16, 2026 at 02:23:48PM -0700, Bobby Eshleman wrote:

On Wed, Sep 16, 2026 at 02:57:43PM +0200, Stefano Garzarella wrote:

quoted

On Tue, Sep 15, 2026 at 11:50:10AM -0700, Bobby Eshleman wrote:

quoted

On Tue, Sep 15, 2026 at 05:28:25PM +0200, Stefano Garzarella wrote:

quoted

On Wed, Sep 02, 2026 at 04:00:48PM -0700, Bobby Eshleman wrote:

quoted

From: Bobby Eshleman <redacted>

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

We already discussed about netlink, but I'm not sure how much work can
take, here just another alternative, what about adding
/proc/sys/net/vsock/g2h_owner sysctl that can be read/write where:
0 - no owner
1 - owner

0 -> 1 transition, move the device in the new nets
1 -> 0 transition, reset back to init_ns

That seems reasonable, but if multi-device support ever lands, this
might be harder to adapt cleanly?

I see, but maybe we can have a dev0/ dev1/ subfolders in that case.

quoted

quoted

quoted

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
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
supports local-mode in the future, this logic will have to be changed.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/ (local)
Signed-off-by: Bobby Eshleman <redacted>
---
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(-)

[...]

quoted

One thing I realized when answering your uAPI questions and looking at
the code is that IOCTL_VM_SOCKETS_GET_LOCAL_CID is not namespace aware,
but I think it probably should be? I remember for host ns we strived for
truly strong isolation.

Can you elabore a bit more?

I'm wondering if IOCTL_VM_SOCKETS_GET_LOCAL_CID should not reveal the

Okay, I see now, too many IOCTL_VM_SOCKETS involved and I didn't get you 
were referring to the GET_LOCAL_CID xD

CID of the g2h device if the device has been moved to an inaccessible
namespace? In this case, fallback to the results of h2g/local and
through to returning VMADDR_CID_ANY if neither of those transports are
loaded.

Yeah, I agree. I'm not 100% sure if it's really an issue if we reveal it 
to any workspace, but I also don't see why we should do that. So, yeah, 
if possible we should reveal it only in the namespace assigned to the 
G2H.

I also considered whether or not /dev/vsock should even be visible from
within an inaccessible namespace in order to not leak even the mere
presence of the vsock device, but it seems to me that /dev/vsock's
presence doesn't leak anything besides the presence of the vsock module.

Will this break userspace doing IOCTL_VM_SOCKETS_GET_LOCAL_CID on 
loopback, etc. ?

Thanks,
Stefano