linux-kernel - 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: <Z8iGWLsQGdTv47je@devvm6277.cco0.facebook.com>
Date: Wed, 5 Mar 2025 09:14:00 -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 Wed, Mar 05, 2025 at 10:42:58AM +0100, Stefano Garzarella wrote:
> On Tue, Mar 04, 2025 at 04:06:02PM -0800, Bobby Eshleman wrote:
> > On Thu, Jan 16, 2020 at 06:24:25PM +0100, Stefano Garzarella wrote:
> > 
> > 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?
> 
> Yes, I guess it makes sense that multiple namespaces can communicate with
> the host and then use the virtio-vsock device!
> 
> IIRC, the main use case here was also nested VMs. So a netns could be used
> to isolate a nested VM in L1 and it may not need to talk to L0, so the
> software in the L1 netns can use vsock, but only to talk to L2.
> 

Oh I see. The ioctl(IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS) makes sense here
and seems like the simplest approach. Maybe we don't want multiple
namespaces for virtio-vsocka then? The problem I see is that then users
might expect non-colliding port spaces, which means there needs to be
some kind of port-mapping, which would then require vsock users to pass
around their port mappings out-of-band...

It sounds like none of our known use cases requires non-colliding ports?

> > 
> > More questions/comments in other parts of this thread.
> 
> Sure, I'm happy to help with this effort with discussions/reviews!
> 

Awesome, thank you!

Best,
Bobby