> > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
