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

[Daniel Henrique Barboza]

On 2/4/19 7:48 AM, Christian Ehrhardt wrote:
> 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.


Good to know. "jus disable ligcap-ng support" wasn't a solution that I 
was going
to propose, but with this info I can explain to other people why this isn't
viable at all.


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

Thanks for the explanation.

What I need to do then is to see exactly  the capabilities Iam missing 
from QEMU
(aside from IPC_LOCK) and see if we can get Libvirt to set them.



Thanks,


DHB


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