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

[Stefano Garzarella]

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:
> > On Tue, Sep 15, 2026 at 11:50:10AM -0700, Bobby Eshleman wrote:
> > > On Tue, Sep 15, 2026 at 05:28:25PM +0200, Stefano Garzarella wrote:
> > > > On Wed, Sep 02, 2026 at 04:00:48PM -0700, 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
> > > >
> > > > 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.
> >
> > >
> > > >
> > > > > 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@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(-)
> > > > >
> >
> > [...]
> >
> > >
> > > 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