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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/libvir-list