On Wed, Mar 05, 2025 at 10:23:08AM +0100, Stefano Garzarella wrote: > On Wed, 5 Mar 2025 at 08:32, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > [...] > > > > > > I'm not sure I understand the usecase. Can you explain a bit more, > > please? > > It's been five years, but I'm trying! > We are tracking this RFE here [1]. > > I also add Jakub in the thread with who I discussed last year a possible > restart of this effort, he could add more use cases. > > The problem with vsock, host-side, currently is that if you launch a VM > with a virtio-vsock device (using vhost) inside a container (e.g., > Kata), so inside a network namespace, it is reachable from any other > container, whereas they would like some isolation. Also the CID is > shared among all, while they would like to reuse the same CID in > different namespaces. > > This has been partially solved with vhost-user-vsock, but it is > inconvenient to use sometimes because of the hybrid-vsock problem > (host-side vsock is remapped to AF_UNIX). > > Something from the cover letter of the series [2]: > > As we partially discussed in the multi-transport proposal, 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 > > Thanks, > Stefano > Do you know of any use cases for guest-side vsock netns? Our use case is also host-side. vsock is used to communicate with a host-side shim/proxy/debug console. Each vmm and these components share a namespace and are isolated from other vmm + components. The VM connects back to the host via vsock after startup and communicates its port of choice out-of-band (fw_cfg). The main problem is in security: untrusted VM programs can potentially connect with and exploit the host-side vsock services meant for other VMs. If vsock respected namespaces, then these host-side services would be unreachable by other VMs and protected. Namespaces would also allow the vsock port to be static across VMs, and avoid the need for the out-of-band mechanism for communicating the port. Jakub can jump in to add anything, but I think this is the same use case / user he was probably referring to. Best, Bobby
