On Wed, 5 Mar 2025 at 16:55, Bobby Eshleman <bobbyeshleman@xxxxxxxxx> wrote: > > 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? Yep, as I mentioned in another mail this morning, the use case is nested VMs or containers running in the L1 guests. Users (e.g. Kata) would like to hide the L0<->L1 vsock channel in the container, so anything running there can't talk with the L0 host. BTW we can do that incrementally if it's too complicated. > > 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. Yeah, I see. Thanks, Stefano > > Jakub can jump in to add anything, but I think this is the same use case > / user he was probably referring to. > > Best, > Bobby >
