> First the addressing is non-trivial, especially with the "transport > specific device address" in the tuple. There is complexity here, but I think it would also be present in the buffer sharing device case. With a buffer sharing device, the same identifying information would need to be provided from the exporting driver to the buffer sharing driver, so the buffer sharing device would be able to identify the right device in the vmm. And then in both import cases, the buffer is just identified by some opaque bytes that need to be given to a buffer manager in the vmm to resolve the actual buffer. > Second I think it is a bad idea > from the security point of view. When explicitly exporting buffers it > is easy to restrict access to the actual exports. Restricting access to actual exports could perhaps help catch bugs. However, I don't think it provides any security guarantees, since the guest can always just export every buffer before using it. Using implicit addresses doesn't mean that the buffer import actually has to be allowed - it can be thought of as fusing the buffer export and buffer import operations into a single operation. The vmm can still perform exactly the same security checks. > Instead of using a dedicated buffer sharing device we can also use > virtio-gpu (or any other driver which supports dma-buf exports) to > manage buffers. I don't think adding generic buffer management to virtio-gpu (or any specific device type) is a good idea, since that device would then become a requirement for buffer sharing between unrelated devices. For example, it's easy to imagine a device with a virtio-camera and a virtio-encoder (although such protocols don't exist today). It wouldn't make sense to require a virtio-gpu device to allow those two devices to share buffers. > With no central instance (buffer sharing device) being there managing > the buffer identifiers I think using uuids as identifiers would be a > good idea, to avoid clashes. Also good for security because it's pretty > much impossible to guess buffer identifiers then. Using uuids to identify buffers would work. The fact that it provides a single way to refer to both guest and host allocated buffers is nice. And it could also directly apply to sharing resources other than buffers (e.g. fences). Although unless we're positing that there are different levels of trust within the guest, I don't think uuids really provides much security. If we're talking about uuids, they could also be used to simplify my proposed implicit addressing scheme. Each device could be assigned a uuid, which would simplify the shared resource identifier to (device-uuid, shmid, offset). In my opinion, the implicit buffer addressing scheme is fairly similar to the uuid proposal. As I see it, the difference is that one is referring to resources as uuids in a global namespace, whereas the other is referring to resources with fully qualified names. Beyond that, the implementations would be fairly similar. -David
