feat: support secure boot with Microsoft keys

[alexhaydock]

Currently, Quickemu supports enabling Secure Boot with secureboot=on, and this causes a Secure Boot compatible UEFI image to be loaded.

Example below is what gets picked on Fedora: https://github.com/quickemu-project/quickemu/blob/3940f7b4521ee840c6811dde120734df97dc0e07/quickemu#L390

But this image doesn't contain the actual default Microsoft Platform Keys for Secure Boot - instead, they're loaded into the NVRAM, which gets stored in OVMF_VARS.fd. Using Fedora as an example, this file gets sourced from here: https://github.com/quickemu-project/quickemu/blob/3940f7b4521ee840c6811dde120734df97dc0e07/quickemu#L391

But that NVRAM image isn't the one with the keys enrolled in it. That image is stored here:

/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd

So this means that, functionally, using secureboot=on doesn't actually turn Secure Boot on in the way a user might expect, since Secure Boot is available in the UEFI but is disabled (because it doesn't have any keys to validate against).

If I change line 391 (linked above) to the following:

          efi_vars "/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd" "${EFI_VARS}"

this works fine. The UEFI has the Microsoft Platform Key(s) enrolled, and Secure Boot is enabled by default.

Is it worth me submitting a PR to add support for this?

WARNING There's a potential caveat to be aware of though before we pull in such a PR - which is that if you're using Quickemu to run Windows and Secure Boot is properly enabled, the Windows Driver Signing Policy requirements demand that you have WHQL-signed drivers blessed by Microsoft's keys in order for them to be allowed to load.

This might cause some confusion or annoyance if we pull this in without any other safeguards, because the common strategy of downloading the virtio-win.iso from the FedoraPeople site won't work. The drivers for the VirtIO components are signed by Red Hat's keys, but they're not WHQL-signed by Microsoft.

But Red Hat does actually make these available as part of the virtio-win package. And they work completely fine. I just think you have to be a paying RHEL subscriber to be able to get those ones.

TESTED AND WORKING Here's an example of fully-working Secure Boot on Windows 10 inside Quickemu on Fedora 35, with only the one-line change above (and the VirtIO drivers from the virtio-win package from a paid RHEL subscription):

[github-actions[bot]]

Hello there 👋 Thanks for submitting your first issue to the Quickemu project 🐛 We'll try and take a look at your issue soon ⏲

In the meantime you might want to join the Wimpys World Discord 🗣 where we have a large community of Linux 🐧 enthusiasts and passionate open source developers 🧑‍💻

You might also be interested in following Wimpys World Twitch 📡 channel where Wimpy streams let's code video, including this project, several times a week. A back catalog of past live stream and other Linux related content is available on Wimpys World YouTube 📺 channel.

[linsui]

RedHat provides WHQL signed packages in CentOS http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/:

• VirtIO driver (virtio-win)
• OVMF with Microsoft keys (edk2-ovmf)
• Windows guest tools (spice-client-win)
• Windows SPICE agent (spice-vdagent-win)

quickget should download them.

[alexhaydock]

RedHat provides WHQL signed packages in CentOS http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/:

• VirtIO driver (virtio-win)
• OVMF with Microsoft keys (edk2-ovmf)
• Windows guest tools (spice-client-win)
• Windows SPICE agent (spice-vdagent-win)

quickget should download them.

Great find! Thanks for this.

For what it's worth, for anyone else reading this ticket - I can confirm that I can still replicate what you see in the image above (i.e. fully-working Secure Boot on Windows 10 or 11 with all the various features enabled), but I've found that trying to boot Linux images with the same settings seems to fail, even when those images are ones which definitely support Secure Boot (i.e. Fedora/Ubuntu). So some caution may be required when implementing anything to do with this that might end up becoming a default. I haven't had time to test that behaviour though and find an explanation.