netdev - Re: [PATCH net-next 0/3] vsock: support network namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z8eVanBR7r90FK7m@devvm6277.cco0.facebook.com>
Date: Tue, 4 Mar 2025 16:06:02 -0800
From: Bobby Eshleman <bobbyeshleman@...il.com>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jorgen Hansen <jhansen@...are.com>,
	Jason Wang <jasowang@...hat.com>, kvm@...r.kernel.org,
	Stefan Hajnoczi <stefanha@...hat.com>,
	virtualization@...ts.linux-foundation.org,
	linux-hyperv@...r.kernel.org, "Michael S. Tsirkin" <mst@...hat.com>,
	Dexuan Cui <decui@...rosoft.com>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 0/3] vsock: support network namespace

On Thu, Jan 16, 2020 at 06:24:25PM +0100, Stefano Garzarella wrote:
> RFC -> v1:
>  * added 'netns' module param to vsock.ko to enable the
>    network namespace support (disabled by default)
>  * added 'vsock_net_eq()' to check the "net" assigned to a socket
>    only when 'netns' support is enabled
> 
> RFC: https://patchwork.ozlabs.org/cover/1202235/
> 
> Now that we have multi-transport upstream, I started to take a look to
> support network namespace in vsock.
> 
> As we partially discussed in the multi-transport proposal [1], it could
> be nice to support network namespace in vsock to reach the following
> goals:
> - isolate host applications from guest applications using the same ports
>   with CID_ANY
> - assign the same CID of VMs running in different network namespaces
> - partition VMs between VMMs or at finer granularity
> 
> This new feature is disabled by default, because it changes vsock's
> behavior with network namespaces and could break existing applications.
> It can be enabled with the new 'netns' module parameter of vsock.ko.
> 
> This implementation provides the following behavior:
> - packets received from the host (received by G2H transports) are
>   assigned to the default netns (init_net)
> - packets received from the guest (received by H2G - vhost-vsock) are
>   assigned to the netns of the process that opens /dev/vhost-vsock
>   (usually the VMM, qemu in my tests, opens the /dev/vhost-vsock)
>     - for vmci I need some suggestions, because I don't know how to do
>       and test the same in the vmci driver, for now vmci uses the
>       init_net
> - loopback packets are exchanged only in the same netns


Hey Stefano,

I recently picked up this series and am hoping to help update it / get
it merged to address a known use case. I have some questions and
thoughts (in other parts of this thread) and would love some
suggestions!

I already have a local branch with this updated with skbs and using
/dev/vhost-vsock-netns to opt-in the VM as per the discussion in this
thread.

One question: what is the behavior we expect from guest namespaces?  In
v2, you mentioned prototyping a /dev/vsock ioctl() to define the
namespace for the virtio-vsock device. This would mean only one
namespace could use vsock in the guest? Do we want to make sure that our
design makes it possible to support multiple namespaces in the future if
the use case arrives?

More questions/comments in other parts of this thread.

Thanks!

- Bobby