Re: running Libvirt from source code, IPC_LOCK and VFIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

After investigating more I've fixed the problem in a way that I believe it's
worth a patch. I'll be sending it to the ML shortly.


Thanks everyone for the inputs and insights,


DHB

On 2/4/19 10:59 AM, Yuval Shaia wrote:
+ Kamal and Marcel

On Mon, Feb 04, 2019 at 09:58:47AM +0100, Michal Privoznik 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

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.
In my case it is not a matter of risk of a malicious guest, it is that the
device cannot utilize the host device *unless* it has the 'lock'
capability.

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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux