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

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

Hi David,

On Mon, 10 Feb 2020 14:06:21 +0900
David Stevens <stevensd@chromium.org> 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 bridge unix and vsock sockets to make it
> > transparent, ...). The FD <-> VFD mapping would also have to be created
> > on the host side, probably by the virtio device implementation
> > (virglrenderer for GEM bufs for instance), which means host and guest
> > need a way to inform the other end that a new FD <-> VFD mapping has
> > been created so the other end can create a similar mapping (I guess this
> > requires extra device-specific commands to work).  
> 
> My recent proposal for cross device resource sharing seems like it
> could be relevant here: https://markmail.org/thread/jsaoqy7phrqdcpqu.

Thanks for sharing this link. I had a quick look at this proposal, and, 
maybe I'm wrong, but I'm not sure it actually addresses Tomasz' concern
[1] if we keep letting a userspace proxy do the FD <-> UUID conversion
and sending the UUID through the VSOCK. To me, a UUID only guarantees
that 2 buffers will get different UUIDs (assuming they use the same
algorithm to generate this UUID), but nothing prevents a malicious app
from opening a connection to the host proxy and sending valid wayland
messages with forged UUIDs, in the hope that one of them will match an
already exported resource.

Regards,

Boris

[1]https://www.spinics.net/lists/kvm/msg185688.html