[libvirt] running Libvirt from source code, IPC_LOCK and VFIO

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Feb 4 09:48:14 UTC 2019


On Mon, Feb 4, 2019 at 9:59 AM Michal Privoznik <mprivozn at redhat.com> wrote:
>
> On 2/1/19 7:04 PM, Daniel Henrique Barboza wrote:
> > Hi,
> >
> > I'm facing a strange behavior when running Libvirt from source code,
> > latest upstream, on an Ubuntu 18.04.1 LTS Power 9 server. My QEMU
> > guest - which is using VFIO and GPU passthrough - breaks on boot when
> > trying to allocate a DMA window inside KVM.
> >
> > Debugging the code, I've found out that the problem is related to the
> > process
> > not having CAP_IPC_LOCK - at least from the host kernel perspective.
> >
> > This is strange because:
> >
> > - the same VM running directly from QEMU command line works
> > - the same VM running in the system Libvirt (v4.0.0, Ubuntu version)
> > also works

FYI Ubuntu's version is build with capng for the cap dropping feature
as discussed in this thread.
libcap-ng-dev  is installed as build dependencies and "--with-capng"
is set on all Linux builds.


> >
> > What am I missing? My understanding on Linux process is that a process
> > running as root should inherit the same capabilities of the user, which
> > includes
> > CAP_IPC_LOCK. Running Libvirt from source code should grant ipc_lock
> > to it ... right?
>
> No. Ideally, you trust libvirt and want it to manage devices on your
> system thus it needs all the capabilities. But qemu spawn by libvirt
> should have no capabilities as libvirt set up everything that's needed
> for qemu to run. But this is hard to get right - qemu changes and so
> does the capabilities it may require (these depend on domain
> configuration anyway). Therefore, it is possible to set libvirt so it
> does not drop capabilities for qemu process - see
> clear_emulator_capabilities in qemu.conf - but then libvirt can't
> guarantee that a compromised qemu does no harm.
>
> This corresponds with your finding about ./configure - if there is no
> libncap-ng found there's no way for libvirt to drop capabilities and
> thus it doesn't do that.
>
> Michal
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd




More information about the libvir-list mailing list