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

[Gerd Hoffmann <kraxel@redhat.com>]

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).

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.

cheers,
  Gerd