libvirt VS sbctl

Only in trivial cases. The problem is when another part of the program holds a function pointer (eg callback) into the library which has been unloaded.

libvirt has long been linked with -Wl,nodelete to avoid this:

https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f...

So, next I setup cockpit and cockpit-machines, which works to create VMs (via cockpit-machines) but they use tcg/qemu i.e. emulation and no KVM based h/w acceleration - my test VMs were very slow! I figured out while qemu+KVM works on command line, it doesn't work and the culprit was libvirt! After discussing with the good folks on #asahi channel and with tobhe (Ubuntu-Asahi creator), I gathered enough evidence to conclude libvirtd doesn't know the "right" qemu commands to exec and logged my findings to the libvirt project https://gitlab.com/libvirt/libvirt/-/issues/365 (which can probably use some of the community noise, to expedite the fix).

Nvidia 510 introduced a regression you can see the relevant issues here and here

The work to split into multiple daemons started a few years ago.

https://gitlab.com/libvirt/libvirt/-/blob/9b8bb536ff999fa61e...

There have been a few complaints online in the Arch and Gitlab forums regarding this issue. https://gitlab.com/libvirt/libvirt/-/issues/410

The issue stems from a change in libvirt. Libvirt is responsible for parsing all your VM's XML and turning it into a QEMU command. Somewhere between libvirt version 6.6 and version 6.9, there was a slight change in the way USB devices are passed to QEMU, and obviously libvirt followed suit. As a result, some USB passthrough configurations, such as the MacOS one in the thread, as well as the onboard bluetooth for windows suffered errors.

It's a bug, fix is upstream: https://gitlab.com/libvirt/libvirt/-/commit/04736179b283f55f62616a20a1ec95c665aab8ca

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

No problem! The sbctl package ships with a pretty extensive hook out of the box (https://github.com/Foxboron/sbctl/blob/master/contrib/pacman/ZZ-sbctl.hook). It's been very reliable for automatically resigning .efi executables after updates for me.

sbctl verify returns failed to find EFI system partition despite it definitely is there. It's the same issue as this but remounting or restarting doesn't fix it.

lol

Must actually prevent unsigned images from booting

sudo dnf install asciidoc golang -y VERSION=0.11 cd /tmp curl -L "https://github.com/Foxboron/sbctl/releases/download/${VERSION}/sbctl-${VERSION}.tar.gz" | tar zxvf - cd "sbctl-${VERSION}" make sudo make install cd ~

By far the easiest is to use sbctl to generate, install and use keys to sign your efi images. You can use mkinitcpio to build the unified kernels automatically and a pacman trigger to rerun the sbctl signing when the kernel is updated. Pretty straightforward (once you've done it once).

The question is whether you have any UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.

If you're using a TPM for Secure Boot, you can use the command in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.