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

[Michal Privoznik]

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
> 
> 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