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

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

On Tue, 25 Feb 2020 15:55:12 +0000
Alex BennÃe <alex.bennee@linaro.org> wrote:

> Boris Brezillon <boris.brezillon@collabora.com> writes:
> 
> > Hi all,
> >
> > On Fri, 7 Feb 2020 18:28:42 +0100
> > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> >  
> >> Hello everyone,
> >> 
> >> I recently took over Tomeu's task of upstreaming virtio-wayland. After
> >> spending quite a bit of time collecting information from his different
> >> attempts [1][2] I wanted to sync with all the people that were involved
> >> in the previous discussions (if I missed some of them, feel free to add
> >> them back).
> >> 
> >> The goal here is to get a rough idea of the general direction this
> >> should take so I can start implementing a PoC and see if it fits
> >> everyone's needs.
> >> 
> >> virtio-wayland [3] started as a solution to pass wayland messages
> >> between host and guests so the guest can execute wayland apps whose
> >> surface buffers are passed to the wayland compositor running on the
> >> host. While this was its primary use case, I've heard it's been used to
> >> transport other protocols. And that's not surprising, when looking at
> >> the code I noticed it was providing a protocol-agnostic message passing
> >> interface between host and guests, similar to what VSOCK provides but
> >> with FD passing as an extra feature.
> >> 
> >> Based on all previous discussions, I could identify 3 different
> >> approaches:
> >> 
> >>     1/ Use VSOCK and extend it to support passing (some) FDs
> >>     2/ Use a user space VSOCK-based proxy that's in charge of
> >>        a/ passing regular messages
> >>        b/ passing specific handles to describe objects shared
> >>           between host and guest (most focus has been on dmabufs as
> >>           this is what we really care about for the gfx use case,
> >>           but other kind of FDs can be emulated through a
> >>           VSOCK <-> UNIX_SOCK bridging)
> >>     3/ Have a dedicated kernel space solution that provides features
> >>        exposed by #1 but through a virtio device interface (basically
> >>        what virtio-wayland does today)
> >>   
> <snip>
> 
> > Option #1 sounds like a good idea on
> > the paper, but the fact that Google wants a solution that does not
> > involve vhost and given Gerd's concern about being able to use vsock
> > in some cases and do !vsock message-passing in others, it might not be
> > possible to use vsock (there can only be one vsock implementation
> > active).  
> 
> Forgive me for jumping in but what is the concern about vhost here? Is
> it purely the increased attack surface to the kernel or some more
> fundamental issue? Is this something that can be addressed with a
> vhost-user backend where all the complications of the host end are dealt
> with in user-space?

That's a question for Zach or StÃphane, but AFAIU it has to do with the
increased attack surface to the host kernel. Firecraker (which, IIUC, is
a fork of crosvm) had the same request [1] and implemented a !vhost
vsock backend [2] to address that.

[1]https://github.com/firecracker-microvm/firecracker/issues/650
[2]https://github.com/firecracker-microvm/firecracker/pull/1176