search

void-linux / void-packages

The Void source packages collection
https://voidlinux.org
Other
2.57k stars 2.14k forks source link

libvirt-7.5.0_1: [Regression] Unable to create or start VMs #31904

Open noarchwastaken opened 3 years ago

noarchwastaken commented 3 years ago

System

Expected behavior

virsh start <domain> should start the corresponding virtual machine.

Actual behavior

$ doas virsh start voidlinux
error: Failed to start domain 'voidlinux'
error: internal error: cannot load AppArmor profile 'libvirt-aa58ea57-f6d7-48b1-b727-de97f4c508af'

Steps to reproduce the behavior

  1. ~Enable AppArmor~
  2. ~Create a VM using libvirt<=7.4.0_1~
  3. ~Update libvirt to 7.5.0_1, reboot to reload apparmor profiles~
  4. ~Try to launch the VM again~

Edit: The above is with AppArmor profile usr.lib.libvirt.virt-aa-helper unenforced (part of my debugging process)

  1. Enable Apparmor.
  2. Try to start or create any VM.
noarchwastaken commented 3 years ago

Some more info on the bug:

A workaround is to delete /etc/apparmor.d/libvirt, which makes everything work again. This directory doesn't exist in libvirt-7.4.0_1.

With the directory there, every time I try to create a VM, apparmor denies this:

2021-07-22T05:50:57.18772 kern.notice: [  697.561573] audit: type=1400 audit(1626933057.186:725): apparmor="DENIED" operation="exec" profile="virt-aa-helper" name="/usr/b
in/apparmor_parser" pid=4069 comm="virt-aa-helper" requested_mask="x" denied_mask="x" fsuid=0 ouid=0

And that's why I'm able to create and run new VMs with usr.lib.libvirt.virt-aa-helper set to complain mode.

paper42 commented 3 years ago

@noarchwastaken Can you try adjusting this line in usr.lib.libvirt.virt-aa-helper?

/{usr/,}sbin/apparmor_parser Ux

to

/{usr/,}{s,}bin/apparmor_parser Ux

apparmor profiles from upstream projects are often broken because each distribution has different paths, but if fixes your issue, you could upstream it and submit a PR with a patch for the libvirt package.

noarchwastaken commented 3 years ago

@noarchwastaken Can you try adjusting this line in usr.lib.libvirt.virt-aa-helper?

/{usr/,}sbin/apparmor_parser Ux

to

/{usr/,}{s,}bin/apparmor_parser Ux

apparmor profiles from upstream projects are often broken because each distribution has different paths, but if fixes your issue, you could upstream it and submit a PR with a patch for the libvirt package.

With the change, the apparmor_parser warning went away, but I'm still unable to create new UEFI-based VMs... The error is the same.

This time I can't see any kernel log popping up.

Can anyone replicate this issue? I can't strictly control the variables because I'm testing it on my daily driver laptop.

noarchwastaken commented 3 years ago

Note, the last change allows me to create new BIOS-based VM again.

folliehiyuki commented 3 years ago

@noarchwastaken Can you try adjusting this line in usr.lib.libvirt.virt-aa-helper?

/{usr/,}sbin/apparmor_parser Ux

to

/{usr/,}{s,}bin/apparmor_parser Ux

apparmor profiles from upstream projects are often broken because each distribution has different paths, but if fixes your issue, you could upstream it and submit a PR with a patch for the libvirt package.

Can confirm. After applying this change, I can create BIOS VMs. But UEFI VMs are still stuck at the same error.

ghost commented 3 years ago

This is caused by virt-aa-manager as it's trying to automatically generate the AppArmor profile on VM startup.
virt-aa-manager disallows some paths in generated AppArmor profiles which can be found here src/security/virt-aa-helper.c:454-490:valid_path()

I fixed this for the edk2-x86_64-code.fd firmware image by copying the executable and nvram-template files referenced in /usr/share/qemu/firmware/60-edk2-x86_64.json to /usr/share/ovmf.
I then made a copy of 60-edk2-x86_64.json with some other name like: 60-edk2-x86_64-custom.json and updated the file paths in this copied file to reference the ones in /usr/share/ovmf.

Also i am sorry for creating a extra issue.

Edit: Make soulution more clear

noarchwastaken commented 2 years ago

In #32562 (the now) ghost mentioned we could also patch virt-aa-helper, and I prefer it since:

First, looking at restricted-rw[] it's all publicly accessible files with no confidential information. /usr/share/qemu/ also doesn't contain confidential files, so even in the case of a breakout that will be stopped by apparmor, the risk is managable.

Second, the moving firmware to /usr/share/ovmf method breaks existing VM configurations (except maybe we link the firmwares back? But existing VMs still suffer from the same problem, and it requires manual intervention.)

Last, there are several closed PRs attempting to add ovmf so far, and I don't think we need them anymore?

github-actions[bot] commented 2 years ago

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

noarchwastaken commented 2 years ago

Bump. I still have to manually workaround it with every libvirt update.

On July 7, 2022 2:14:04 AM UTC, "github-actions[bot]" @.***> wrote:

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

-- Reply to this email directly or view it on GitHub: https://github.com/void-linux/void-packages/issues/31904#issuecomment-1176964062 You are receiving this because you were mentioned.

Message ID: @.***>