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

[David Stevens <stevensd@chromium.org>]

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

You're correct that it wouldn't really protect against malicious apps.
My email was more about pointing out a mechanism that could
potentially help address the FD <-> VFD mapping.

-David