You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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):
The text was updated successfully, but these errors were encountered:
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.
flexiondotorg
changed the title
Support Secure Boot with Microsoft keys
feat: support secure boot with Microsoft keys
Apr 16, 2024
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:
quickemu/quickemu
Line 390 in 3940f7b
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:quickemu/quickemu
Line 391 in 3940f7b
But that NVRAM image isn't the one with the keys enrolled in it. That image is stored here:
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:
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
![image](https://user-images.githubusercontent.com/13152214/156578216-2f2b6340-0bb9-4236-b235-b97489abd4f5.png)
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):The text was updated successfully, but these errors were encountered: