Documentation/admin-guide/sysctl/net.rst | 18 + include/linux/virtio_vsock.h | 2 + include/net/af_vsock.h | 9 +- include/uapi/linux/vm_sockets.h | 6 + net/vmw_vsock/af_vsock.c | 200 ++++++++- net/vmw_vsock/virtio_transport.c | 28 +- net/vmw_vsock/virtio_transport_common.c | 28 +- tools/testing/selftests/vsock/.gitignore | 1 + tools/testing/selftests/vsock/Makefile | 3 +- tools/testing/selftests/vsock/config | 1 + tools/testing/selftests/vsock/vmtest.sh | 461 ++++++++++++++++++++- .../selftests/vsock/vsock_assign_g2h_netns.c | 45 ++ 12 files changed, 774 insertions(+), 28 deletions(-)
vsock network namespaces let a host put each VM in a namespace of its
own. A guest has no equivalent yet. It has a single G2H device that
cannot be assigned to a network namespace.
This series lets a guest move that device into a network namespace. A
new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the
device to the namespace of the calling process. The namespace's existing
ns_mode then decides who may use it: a "global" namespace shares the
device with every other global namespace, and a "local" namespace keeps
the host connection to itself. The device starts out in the initial
namespace, so until the ioctl is issued nothing has moved and no mode
has changed. There is no explicit unassign as assigning the device back
to the initial namespace is equivalent.
The ioctl requires CAP_NET_ADMIN in the initial user namespace.
Connections that can no longer reach the device after a move are reset,
so that a namespace which has lost access cannot keep using a socket it
opened while it still had access. Following netdevs, the device returns
to the initial namespace when the namespace it was moved to is deleted.
Transports opt in through a new netns_assign_allow callback. Only
virtio-vsock implements it here.
Patch 1 is just a const cleanup that patch 2 needs. The remaining
patches are actual implementation and tests.
Based off of Stefano's original series:
https://lore.kernel.org/all/20200116172428.311437-1-sgarzare@redhat.com/
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
---
Bobby Eshleman (6):
vsock: constify the transport in vsock_for_each_connected_socket()
vsock: add IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS
vsock/virtio: support guest device network namespace
selftests/vsock: add a helper to assign the g2h device to a netns
selftests/vsock: test the guest vsock device network namespace
selftests/vsock: test the assign ioctl privilege checks
Documentation/admin-guide/sysctl/net.rst | 18 +
include/linux/virtio_vsock.h | 2 +
include/net/af_vsock.h | 9 +-
include/uapi/linux/vm_sockets.h | 6 +
net/vmw_vsock/af_vsock.c | 200 ++++++++-
net/vmw_vsock/virtio_transport.c | 28 +-
net/vmw_vsock/virtio_transport_common.c | 28 +-
tools/testing/selftests/vsock/.gitignore | 1 +
tools/testing/selftests/vsock/Makefile | 3 +-
tools/testing/selftests/vsock/config | 1 +
tools/testing/selftests/vsock/vmtest.sh | 461 ++++++++++++++++++++-
.../selftests/vsock/vsock_assign_g2h_netns.c | 45 ++
12 files changed, 774 insertions(+), 28 deletions(-)
---
base-commit: d0ec95a8a4e79f2fd6063fc8932415db8c227689
change-id: 20260831-vsock-guest-ns-d06af451da67
Best regards,
--
Bobby Eshleman <bobbyeshleman@meta.com>
On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: >vsock network namespaces let a host put each VM in a namespace of its >own. A guest has no equivalent yet. It has a single G2H device that >cannot be assigned to a network namespace. Thanks for this, I'll do a proper review next week, in the mean time some comments below: > >This series lets a guest move that device into a network namespace. A >new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the >device to the namespace of the calling process. The namespace's existing Why an ioctl? I'm asking because I'd like to know if you've already considered any alternatives (sysfs, netlink, etc.) How do you think the ioctl should be used? Should we provide an userspace tool, or extending some existing tools? Thanks, Stefano >ns_mode then decides who may use it: a "global" namespace shares the >device with every other global namespace, and a "local" namespace keeps >the host connection to itself. The device starts out in the initial >namespace, so until the ioctl is issued nothing has moved and no mode >has changed. There is no explicit unassign as assigning the device back >to the initial namespace is equivalent. > >The ioctl requires CAP_NET_ADMIN in the initial user namespace. > >Connections that can no longer reach the device after a move are reset, >so that a namespace which has lost access cannot keep using a socket it >opened while it still had access. Following netdevs, the device returns >to the initial namespace when the namespace it was moved to is deleted. > >Transports opt in through a new netns_assign_allow callback. Only >virtio-vsock implements it here. Why? (Not asking to support all the others, asking to explain the reason or ask helps from others to extend it) Thanks, Stefano > >Patch 1 is just a const cleanup that patch 2 needs. The remaining >patches are actual implementation and tests. > >Based off of Stefano's original series: >https://lore.kernel.org/all/20200116172428.311437-1-sgarzare@redhat.com/ > >Suggested-by: Stefano Garzarella <sgarzare@redhat.com> >Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/ > >Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> >--- >Bobby Eshleman (6): > vsock: constify the transport in vsock_for_each_connected_socket() > vsock: add IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS > vsock/virtio: support guest device network namespace > selftests/vsock: add a helper to assign the g2h device to a netns > selftests/vsock: test the guest vsock device network namespace > selftests/vsock: test the assign ioctl privilege checks > > Documentation/admin-guide/sysctl/net.rst | 18 + > include/linux/virtio_vsock.h | 2 + > include/net/af_vsock.h | 9 +- > include/uapi/linux/vm_sockets.h | 6 + > net/vmw_vsock/af_vsock.c | 200 ++++++++- > net/vmw_vsock/virtio_transport.c | 28 +- > net/vmw_vsock/virtio_transport_common.c | 28 +- > tools/testing/selftests/vsock/.gitignore | 1 + > tools/testing/selftests/vsock/Makefile | 3 +- > tools/testing/selftests/vsock/config | 1 + > tools/testing/selftests/vsock/vmtest.sh | 461 ++++++++++++++++++++- > .../selftests/vsock/vsock_assign_g2h_netns.c | 45 ++ > 12 files changed, 774 insertions(+), 28 deletions(-) >--- >base-commit: d0ec95a8a4e79f2fd6063fc8932415db8c227689 >change-id: 20260831-vsock-guest-ns-d06af451da67 > >Best regards, >-- >Bobby Eshleman <bobbyeshleman@meta.com> >
On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote: > On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: > > vsock network namespaces let a host put each VM in a namespace of its > > own. A guest has no equivalent yet. It has a single G2H device that > > cannot be assigned to a network namespace. > > Thanks for this, I'll do a proper review next week, in the mean time some > comments below: > > > > > This series lets a guest move that device into a network namespace. A > > new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the > > device to the namespace of the calling process. The namespace's existing > > Why an ioctl? > > I'm asking because I'd like to know if you've already considered any > alternatives (sysfs, netlink, etc.) > > How do you think the ioctl should be used? Should we provide an userspace > tool, or extending some existing tools? > > Thanks, > Stefano Really only because /dev/vsock exists and the prior series used it. Considering netlink, it might be the better option because there is a lot of prior art solving problems we might have in the future. For example, I was thinking about when users suddenly lose access to vsock, with just the current assign ioctl there is no way for apps or users to figure out why this happened. We can have an ioctl() setter for user, but in netdev world users can actually get a notification via netlink as to which namespace the device went to and what its ifindex is there (see __dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK messages). There is probably more, but that's the case that comes to mind. > > > ns_mode then decides who may use it: a "global" namespace shares the > > device with every other global namespace, and a "local" namespace keeps > > the host connection to itself. The device starts out in the initial > > namespace, so until the ioctl is issued nothing has moved and no mode > > has changed. There is no explicit unassign as assigning the device back > > to the initial namespace is equivalent. > > > > The ioctl requires CAP_NET_ADMIN in the initial user namespace. > > > > Connections that can no longer reach the device after a move are reset, > > so that a namespace which has lost access cannot keep using a socket it > > opened while it still had access. Following netdevs, the device returns > > to the initial namespace when the namespace it was moved to is deleted. > > > > Transports opt in through a new netns_assign_allow callback. Only > > virtio-vsock implements it here. > > Why? (Not asking to support all the others, asking to explain the reason or > ask helps from others to extend it) > > Thanks, > Stefano Sure, can add a note here about extending it. I just didn't want to implement code without having an environment allowing me to test it. Best, Bobby
On Fri, Sep 04, 2026 at 10:30:28AM -0700, Bobby Eshleman wrote: >On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote: >> On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: >> > vsock network namespaces let a host put each VM in a namespace of its >> > own. A guest has no equivalent yet. It has a single G2H device that >> > cannot be assigned to a network namespace. >> >> Thanks for this, I'll do a proper review next week, in the mean time some >> comments below: >> >> > >> > This series lets a guest move that device into a network namespace. A >> > new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the >> > device to the namespace of the calling process. The namespace's existing >> >> Why an ioctl? >> >> I'm asking because I'd like to know if you've already considered any >> alternatives (sysfs, netlink, etc.) >> >> How do you think the ioctl should be used? Should we provide an userspace >> tool, or extending some existing tools? >> >> Thanks, >> Stefano > >Really only because /dev/vsock exists and the prior series used it. Yeah, I vaguely remember that we may have discussed switching to netlink in that thread, but I can't find it. > >Considering netlink, it might be the better option because there is a >lot of prior art solving problems we might have in the future. For >example, I was thinking about when users suddenly lose access to vsock, >with just the current assign ioctl there is no way for apps or users to >figure out why this happened. We can have an ioctl() setter for user, >but in netdev world users can actually get a notification via netlink as >to which namespace the device went to and what its ifindex is there (see >__dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK >messages). There is probably more, but that's the case that comes to >mind. netlink seems like the right way to go, do you think it'll be a real pain to implement? > >> >> > ns_mode then decides who may use it: a "global" namespace shares the >> > device with every other global namespace, and a "local" namespace keeps >> > the host connection to itself. The device starts out in the initial >> > namespace, so until the ioctl is issued nothing has moved and no mode >> > has changed. There is no explicit unassign as assigning the device back >> > to the initial namespace is equivalent. >> > >> > The ioctl requires CAP_NET_ADMIN in the initial user namespace. >> > >> > Connections that can no longer reach the device after a move are reset, >> > so that a namespace which has lost access cannot keep using a socket it >> > opened while it still had access. Following netdevs, the device returns >> > to the initial namespace when the namespace it was moved to is deleted. >> > >> > Transports opt in through a new netns_assign_allow callback. Only >> > virtio-vsock implements it here. >> >> Why? (Not asking to support all the others, asking to explain the reason or >> ask helps from others to extend it) >> >> Thanks, >> Stefano > >Sure, can add a note here about extending it. I just didn't want to >implement code without having an environment allowing me to test it. It's fine, I'm not asking you to do it ;-) Sorry again for the delay, I hope to review this series today/tomorrow. Thanks, Stefano
On Tue, Sep 15, 2026 at 12:16:47PM +0200, Stefano Garzarella wrote: > On Fri, Sep 04, 2026 at 10:30:28AM -0700, Bobby Eshleman wrote: > > On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote: > > > On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: > > > > vsock network namespaces let a host put each VM in a namespace of its > > > > own. A guest has no equivalent yet. It has a single G2H device that > > > > cannot be assigned to a network namespace. > > > > > > Thanks for this, I'll do a proper review next week, in the mean time some > > > comments below: > > > > > > > > > > > This series lets a guest move that device into a network namespace. A > > > > new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the > > > > device to the namespace of the calling process. The namespace's existing > > > > > > Why an ioctl? > > > > > > I'm asking because I'd like to know if you've already considered any > > > alternatives (sysfs, netlink, etc.) > > > > > > How do you think the ioctl should be used? Should we provide an userspace > > > tool, or extending some existing tools? > > > > > > Thanks, > > > Stefano > > > > Really only because /dev/vsock exists and the prior series used it. > > Yeah, I vaguely remember that we may have discussed switching to netlink in > that thread, but I can't find it. > > > > > Considering netlink, it might be the better option because there is a > > lot of prior art solving problems we might have in the future. For > > example, I was thinking about when users suddenly lose access to vsock, > > with just the current assign ioctl there is no way for apps or users to > > figure out why this happened. We can have an ioctl() setter for user, > > but in netdev world users can actually get a notification via netlink as > > to which namespace the device went to and what its ifindex is there (see > > __dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK > > messages). There is probably more, but that's the case that comes to > > mind. > > netlink seems like the right way to go, do you think it'll be a real pain to > implement? It is really not bad... it'll include a yaml spec in Documentation/netlink/specs/ of call names and perms, a new target for generated code in the Makefile, a handler, and then tools/net/ynl/ynl-regen.sh generates the plumbing. > > > > > > > > > > ns_mode then decides who may use it: a "global" namespace shares the > > > > device with every other global namespace, and a "local" namespace keeps > > > > the host connection to itself. The device starts out in the initial > > > > namespace, so until the ioctl is issued nothing has moved and no mode > > > > has changed. There is no explicit unassign as assigning the device back > > > > to the initial namespace is equivalent. > > > > > > > > The ioctl requires CAP_NET_ADMIN in the initial user namespace. > > > > > > > > Connections that can no longer reach the device after a move are reset, > > > > so that a namespace which has lost access cannot keep using a socket it > > > > opened while it still had access. Following netdevs, the device returns > > > > to the initial namespace when the namespace it was moved to is deleted. > > > > > > > > Transports opt in through a new netns_assign_allow callback. Only > > > > virtio-vsock implements it here. > > > > > > Why? (Not asking to support all the others, asking to explain the reason or > > > ask helps from others to extend it) > > > > > > Thanks, > > > Stefano > > > > Sure, can add a note here about extending it. I just didn't want to > > implement code without having an environment allowing me to test it. > > It's fine, I'm not asking you to do it ;-) > > Sorry again for the delay, I hope to review this series today/tomorrow. > > Thanks, > Stefano > No rush! Thanks, Bobby
On Tue, Sep 15, 2026 at 10:43:23AM -0700, Bobby Eshleman wrote: >On Tue, Sep 15, 2026 at 12:16:47PM +0200, Stefano Garzarella wrote: >> On Fri, Sep 04, 2026 at 10:30:28AM -0700, Bobby Eshleman wrote: >> > On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote: >> > > On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: >> > > > vsock network namespaces let a host put each VM in a namespace of its >> > > > own. A guest has no equivalent yet. It has a single G2H device that >> > > > cannot be assigned to a network namespace. >> > > >> > > Thanks for this, I'll do a proper review next week, in the mean time some >> > > comments below: >> > > >> > > > >> > > > This series lets a guest move that device into a network namespace. A >> > > > new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the >> > > > device to the namespace of the calling process. The namespace's existing >> > > >> > > Why an ioctl? >> > > >> > > I'm asking because I'd like to know if you've already considered any >> > > alternatives (sysfs, netlink, etc.) >> > > >> > > How do you think the ioctl should be used? Should we provide an userspace >> > > tool, or extending some existing tools? >> > > >> > > Thanks, >> > > Stefano >> > >> > Really only because /dev/vsock exists and the prior series used it. >> >> Yeah, I vaguely remember that we may have discussed switching to netlink in >> that thread, but I can't find it. >> >> > >> > Considering netlink, it might be the better option because there is a >> > lot of prior art solving problems we might have in the future. For >> > example, I was thinking about when users suddenly lose access to vsock, >> > with just the current assign ioctl there is no way for apps or users to >> > figure out why this happened. We can have an ioctl() setter for user, >> > but in netdev world users can actually get a notification via netlink as >> > to which namespace the device went to and what its ifindex is there (see >> > __dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK >> > messages). There is probably more, but that's the case that comes to >> > mind. >> >> netlink seems like the right way to go, do you think it'll be a real pain to >> implement? > >It is really not bad... it'll include a yaml spec in >Documentation/netlink/specs/ of call names and perms, a new target for >generated code in the Makefile, a handler, and then >tools/net/ynl/ynl-regen.sh generates the plumbing. Ah, nice! So, do you want to try that direction? Thanks, Stefano
On Wed, Sep 16, 2026 at 02:36:07PM +0200, Stefano Garzarella wrote: > On Tue, Sep 15, 2026 at 10:43:23AM -0700, Bobby Eshleman wrote: > > On Tue, Sep 15, 2026 at 12:16:47PM +0200, Stefano Garzarella wrote: > > > On Fri, Sep 04, 2026 at 10:30:28AM -0700, Bobby Eshleman wrote: > > > > On Fri, Sep 04, 2026 at 10:55:17AM +0200, Stefano Garzarella wrote: > > > > > On Wed, Sep 02, 2026 at 04:00:46PM -0700, Bobby Eshleman wrote: > > > > > > vsock network namespaces let a host put each VM in a namespace of its > > > > > > own. A guest has no equivalent yet. It has a single G2H device that > > > > > > cannot be assigned to a network namespace. > > > > > > > > > > Thanks for this, I'll do a proper review next week, in the mean time some > > > > > comments below: > > > > > > > > > > > > > > > > > This series lets a guest move that device into a network namespace. A > > > > > > new ioctl on /dev/vsock, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS, assigns the > > > > > > device to the namespace of the calling process. The namespace's existing > > > > > > > > > > Why an ioctl? > > > > > > > > > > I'm asking because I'd like to know if you've already considered any > > > > > alternatives (sysfs, netlink, etc.) > > > > > > > > > > How do you think the ioctl should be used? Should we provide an userspace > > > > > tool, or extending some existing tools? > > > > > > > > > > Thanks, > > > > > Stefano > > > > > > > > Really only because /dev/vsock exists and the prior series used it. > > > > > > Yeah, I vaguely remember that we may have discussed switching to netlink in > > > that thread, but I can't find it. > > > > > > > > > > > Considering netlink, it might be the better option because there is a > > > > lot of prior art solving problems we might have in the future. For > > > > example, I was thinking about when users suddenly lose access to vsock, > > > > with just the current assign ioctl there is no way for apps or users to > > > > figure out why this happened. We can have an ioctl() setter for user, > > > > but in netdev world users can actually get a notification via netlink as > > > > to which namespace the device went to and what its ifindex is there (see > > > > __dev_change_net_namespace() for the RTM_DELLINK and RTM_NEWLINK > > > > messages). There is probably more, but that's the case that comes to > > > > mind. > > > > > > netlink seems like the right way to go, do you think it'll be a real pain to > > > implement? > > > > It is really not bad... it'll include a yaml spec in > > Documentation/netlink/specs/ of call names and perms, a new target for > > generated code in the Makefile, a handler, and then > > tools/net/ynl/ynl-regen.sh generates the plumbing. > > Ah, nice! So, do you want to try that direction? > > Thanks, > Stefano > Let's give it a go. I have a draft of it for v2 and looks reasonable to me. Best, Bobby
© 2016 - 2026 Red Hat, Inc.