On Thu, Dec 12, 2019 at 09:26:32PM +0900, David Stevens wrote:
> > > > 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.
> >
> > Probably not on the guest/host boundary.
> >
> > It's important for security inside the guest though. You don't want
> > process A being able to access process B private resources via buffer
> > sharing support, by guessing implicit buffer identifiers.
>
> At least for the linux guest implementation, I wouldn't think the
> uuids would be exposed from the kernel. To me, it seems like something
> that should be handled internally by the virtio drivers.
That would be one possible use case, yes. The exporting driver attaches
a uuid to the dma-buf. The importing driver can see the attached uuid
and use it (if supported, otherwise run with the scatter list). That
will be transparent to userspace, apps will just export/import dma-bufs
as usual and not even notice the uuid.
I can see other valid use cases though: A wayland proxy could use
virtio-gpu buffer exports for shared memory and send the buffer uuid
to the host over some stream protocol (vsock, tcp, ...). For that to
work we have to export the uuid to userspace, for example using a ioctl
on the dma-buf file handle.
> If you use some other guest with untrusted
> userspace drivers, or if you're pulling the uuids out of the kernel to
> give to some non-virtio transport, then I can see it being a concern.
I strongly prefer a design where we don't have to worry about that
concern in the first place instead of discussing whenever we should be
worried or not.
> > Without buffer sharing support the driver importing a virtio-gpu dma-buf
> > can send the buffer scatter list to the host. So both virtio-gpu and
> > the other device would actually access the same guest pages, but they
> > are not aware that the buffer is shared between devices.
>
> With the uuid approach, how should this case be handled? Should it be
> equivalent to exporting and importing the buffer which was created
> first? Should the spec say it's undefined behavior that might work as
> expected but might not, depending on the device implementation? Does
> the spec even need to say anything about it?
Using the uuid is an optional optimization. I'd expect the workflow be
roughly this:
(1) exporting driver exports a dma-buf as usual, additionally attaches
a uuid to it and notifies the host (using device-specific commands).
(2) importing driver will ask the host to use the buffer referenced by
the given uuid.
(3) if (2) fails for some reason use the dma-buf scatter list instead.
Of course only virtio drivers would try step (2), other drivers (when
sharing buffers between intel gvt device and virtio-gpu for example)
would go straight to (3).
> > With buffer sharing virtio-gpu would attach a uuid to the dma-buf, and
> > the importing driver can send the uuid (instead of the scatter list) to
> > the host. So the device can simply lookup the buffer on the host side
> > and use it directly. Another advantage is that this enables some more
> > use cases like sharing buffers between devices which are not backed by
> > guest ram.
>
> Not just buffers not backed by guest ram, but things like fences. I
> would suggest the uuids represent 'exported resources' rather than
> 'exported buffers'.
Hmm, I can't see how this is useful. Care to outline how you envision
this to work in a typical use case?
cheers,
Gerd
