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

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(a)redhat.com&gt; >>>> --- >>>> 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.