[virglrenderer-devel] coherent memory access for virgl

Tomeu Vizoso tomeu.vizoso at collabora.com
Fri Mar 8 14:02:51 UTC 2019


On 3/8/19 2:39 PM, Gerd Hoffmann wrote:
> On Fri, Mar 08, 2019 at 02:10:54PM +0100, Tomeu Vizoso wrote:
>> On 3/8/19 2:08 PM, Gerd Hoffmann wrote:
>>> On Fri, Mar 08, 2019 at 10:43:04AM +0100, Tomeu Vizoso wrote:
>>>> On 10/11/18 1:04 PM, Gerd Hoffmann wrote:
>>>>>
>>>>>> * virtio-gpu resource IDs are placed by the guest proxy in the wl_dmabuf
>>>>>> protocol stream instead of (guest) dmabuf FDs. The proxy in the host
>>>>>> replaces those to the corresponding (host) dmabuf FD.
>>>>>
>>>>> Yes.
>>>>
>>>> Hi Gerd,
>>>>
>>>> how were you thinking that we would prevent a malicious guest from
>>>> connecting to the host proxy via VSOCK and guessing virtio-gpu resource IDs?
>>>
>>> Each virtio-gpu device (and therefore each guest) has its own resource
>>> id namespace, so you can't guess IDs of other guests.  Guessing IDs of
>>> other processes in the same guest is probably possible.  I think that
>>> doesn't allow actually accessing these resources, you can only ask the
>>> host to do something with them.
>>>
>>> Maybe that is a good reason do make wayland proxying a virtio-gpu
>>> extension.  That way guest userspace would not deal with virtio-gpu
>>> resource IDs but with gbm handles, and the virtio-gpu drm driver would
>>> translate gbm handles to resource ids before proxying buffer control
>>> messages to the host side.
>>
>> By virtio-gpu extension you mean adding ioctls to send and receive protocol
>> data along with references to buffers?
> 
> That'll probably work best.  Also a virtio protocol extension.

Ok, then if you think this is the correct approach, I will work on 
rebasing the series below:

https://lkml.org/lkml/2018/1/26/311

Cheers,

Tomeu


More information about the virglrenderer-devel mailing list