[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)

[Boris Brezillon <boris.brezillon@collabora.com>]

On Mon, 24 Feb 2020 13:45:13 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> On Mon, 24 Feb 2020 13:12:55 +0100
> Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> > On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote:  
> > > On Mon, 17 Feb 2020 19:21:50 +0100
> > > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> > >     
> > > > > > Thats why I don't like the new virtio device idea much and would prefer
> > > > > > vhost being reused, either directly (#1) or via proxy (#2).      
> > > > > 
> > > > > For crosvm's purposes, we are looking at ways to reduce vhost usage in
> > > > > order to reduce host kernel exposure to untrusted guest input,
> > > > > including from the guest kernel. That is why a non-vhost based
> > > > > solution would be prefered.      
> > > > 
> > > > Okay, I didn't know you were avoiding vhost-based solutions to
> > > > reduce the attack surface.    
> > > 
> > > Looks like they implemented vhost-less vsock in Firecracker[1]. Not
> > > sure how much work that would be to port this implementation to crosvm,
> > > but maybe that's an option.
> > > 
> > > [1]https://github.com/firecracker-microvm/firecracker/pull/1176    
> > 
> > Well, the nice thing about vsock is that (a) you have the same interface
> > on guest and host, and (b) it is hypervisor-agnostic.  Applications can
> > simply use the usual system calls (socket, bind, listen, connect) with
> > AF_VSOCK socket type and be done with it.
> > 
> > When not using vhost this goes away (on the host side).  firecracker
> > seems to have a vsock <-> unix socket bridge in vmm userspace instead
> > (pull req msg sounds like that, didn't check the code).  
> 
> That's also my understanding. Note that you still keep the genericity
> on the guest side, which is a good thing I guess.
> 
> > 
> > I think there can be only one vsock device per guest.  So you can't have
> > multiple instances, one with a vsock backend on the host and one with a
> > userspace backend on the host, then pick one of the two depending on the
> > use case.
> > 
> > So, one advantage of a separate device would be that we'll gain some
> > flexibility in terms of the host side implementation.  vsock vhost can
> > be used together with a wayland userspace backend.  
> 
> Yes, though if you really want to avoid vhost to reduce the attack
> surface, you'll probably want to never use vhost instead of having this
> restriction on a per-use-case basis.
> 
> But let's say we go for a dedicated virtio-device to preserve this
> granularity. Should we aim at providing a generic virtio-msg device or
> should we keep this so-called wayland-specific virtio device (I'd like
> to remind you that it's actually protocol-agnostic)?

Maybe there's another option (not sure I mentioned it previously):
de-correlate the message passing and fd-passing interfaces. If we add a
virtio-fd device that takes care of FD passing between guest and host,
we can still use a regular vsock to pass messages (can be vhost or
!vhost depending on your level of paranoïa). The wayland proxies would
then queue/dequeue messages to/from the vsock and FDs to/from virtio-fd.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org