Hi David, On Mon, 10 Feb 2020 14:06:21 +0900 David Stevens <[email protected]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
