[libvirt] [PATCH] qemu: Allow /dev/dri/renderD128

Cole Robinson crobinso at redhat.com
Thu Feb 9 21:39:16 UTC 2017


On 02/08/2017 05:28 AM, Michal Privoznik wrote:
> On 02/08/2017 11:16 AM, Daniel P. Berrange wrote:
>> On Wed, Feb 08, 2017 at 10:44:53AM +0100, Michal Privoznik wrote:
>>> On 02/08/2017 10:31 AM, Daniel P. Berrange wrote:
>>>> On Wed, Feb 08, 2017 at 10:26:26AM +0100, Michal Privoznik wrote:
>>>>> This demand comes from qemu_egl_rendernode_open() in qemu source
>>>>> code. It is needed for virgl to work with qemu:///system
>>>>> connection. The session one works just fine.
>>>>>
>>>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>>>> ---
>>>>>  docs/drvqemu.html.in               | 1 +
>>>>>  src/qemu/qemu.conf                 | 3 ++-
>>>>>  src/qemu/qemu_cgroup.c             | 1 +
>>>>>  src/qemu/test_libvirtd_qemu.aug.in | 1 +
>>>>>  4 files changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>>> diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
>>>>> index 6c90d46d1..b47f714fc 100644
>>>>> --- a/src/qemu/qemu_cgroup.c
>>>>> +++ b/src/qemu/qemu_cgroup.c
>>>>> @@ -47,6 +47,7 @@ const char *const defaultDeviceACL[] = {
>>>>>      "/dev/random", "/dev/urandom",
>>>>>      "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
>>>>>      "/dev/rtc", "/dev/hpet", "/dev/vfio/vfio",
>>>>> +    "/dev/dri/renderD128",
>>>>
>>>> Surely this is only needed in very specific scenarios. ie with
>>>> the virtio-vga 3d rendering enabled.
>>>>
>>>> Allowing unconditional access to the DRI devices is a big
>>>> wide open door from security POV, for something few VMs
>>>> will ever need.
>>>>
>>>> The global device whitelist is only for devices that we
>>>> expect every QEMU to unconditionally require.
>>>
>>> I can argue the same about /dev/vfio/vfio and yet we have it on the list.
>>
>> I consider that to be a bug we should fix too. It should only ever have
>> been added if the guest is actually using vfio.
> 
> Agreed. So just to be clear on the design, if we automatically enable
> /dev/vfio/vfio in devices cgroup on domain startup (of course only for
> domains that are doing pci passtrhough^Wassignment), you would be okay
> with that?
> Similarly, allowing /dev/dri/renderD128 for domains with virgl on their
> startup.
> 

Note, check jtomko's earlier patch which aims to do that for /dev/dri/renderD128

- Cole




More information about the libvir-list mailing list