On Thu, Jul 21, 2022 at 05:09:15PM +0200, Michal Prívozník wrote: > On 7/21/22 16:29, Daniel P. Berrangé wrote: > > On Thu, Jul 21, 2022 at 04:10:11PM +0200, Michal Prívozník wrote: > >> On 7/21/22 15:24, Daniel P. Berrangé wrote: > >>> On Thu, Jul 21, 2022 at 03:12:05PM +0200, Michal Prívozník wrote: > >>>> On 7/21/22 10:06, Daniel P. Berrangé wrote: > >>>> Agreed. While libvirt can allow /dev/sgx* in CGroups (we do that for > >>>> other devices, including NVDIMM and virtio-pmem types of <memory/>), > >>>> it's more tricky with relabelling. > >>>> > >>>> By default, when available, libvirt creates a separate mount namespace > >>>> for each QEMU process and creates a very small /dev there, with only > >>>> those nodes that QEMU needs. Now, if libvirt is fixed (I have follow up > >>>> patches on top of this series) the /dev/sgx* nodes are created there AND > >>>> I have another patch that sets DAC/SELinux label on them so that uid=0 > >>>> is no longer needed. What I worry about though, is the case when this > >>>> namespace feature is disabled. Then libvirt should not touch /dev/sgx* > >>>> because that might compromise security in the system. > >>> > >>> That might in turn require the ability to pass in pre-opened FDs for > >>> the devices to QEMU. > >> > >> Yeah, that might be the perfect solution, but IIUC there's currently no > >> way to achieve that, or is it? Is it something we should do in QEMU first? > > > > The code uses 'qemu_open', so it should be possible already with > > FD passing, by using a /dev/fdset/NNN path. > > But there's no attribute that libvirt provides a path to. How does FD > passing work in such case then? Oh right, I forgot, so this can't be used as is. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
