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

2020-02-17 Thread Boris Brezillon
On Mon, 17 Feb 2020 09:47:46 -0800 Zach Reizner 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

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

2020-02-17 Thread Boris Brezillon
On Fri, 7 Feb 2020 18:28:42 +0100 Boris Brezillon wrote: > 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

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

2020-02-17 Thread Boris Brezillon
On Mon, 17 Feb 2020 13:32:16 +0100 Gerd Hoffmann wrote: > Hi, > > > As pointed in my reply to David's email, I'm a bit worried by the > > security implications of this approach. As long as the dmabuf -> UUID > > conversion stays in kernel space we should be safe, but if we start > > allowing

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

2020-02-17 Thread Gerd Hoffmann
Hi, > As pointed in my reply to David's email, I'm a bit worried by the > security implications of this approach. As long as the dmabuf -> UUID > conversion stays in kernel space we should be safe, but if we start > allowing a guest proxy (running in userland) to send raw UUIDs on a > VSOCK

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

2020-02-17 Thread Boris Brezillon
Hi Stéphane, On Mon, 10 Feb 2020 12:01:02 -0800 Stéphane Marchesin wrote: > On Fri, Feb 7, 2020 at 9:28 AM Boris Brezillon < > boris.brezil...@collabora.com> wrote: > > > Hello everyone, > > > > I recently took over Tomeu's task of upstreaming virtio-wayland. After > > spending quite a bit

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

2020-02-17 Thread Boris Brezillon
Hi Gerd, Sorry for the delay, I was OOO last week. On Mon, 10 Feb 2020 14:38:56 +0100 Gerd Hoffmann wrote: > Hi, > > > #1 might require extra care if we want to make it safe, as pointed > > out by Stefan here [4] (but I wonder if the problem is not the same > > for a virtio-wayland based

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

2020-02-17 Thread David Stevens
> > > FD <-> VFD mappings would have to be created > > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > > sockets if we decide to bridge unix and vsock sockets to make it > > > transparent, ...).

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

2020-02-17 Thread Boris Brezillon
Hi David, On Mon, 10 Feb 2020 14:06:21 +0900 David Stevens wrote: > > FD <-> VFD mappings would have to be created > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > sockets if we decide to