QEMU, OVMF and Secure Boot
Description and usage
Script to generate an OVMF variables ("VARS") file with default Secure Boot keys enrolled. (And verify that it works.)
Simplest working invocation of the script is:
$ ./ovmf-vars-generator output-VARS.fd
But, a more tedious variant where you can invoke the script with custom paths and URLs:
$ ./ovmf-vars-generator \ --ovmf-binary /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd \ --uefi-shell-iso /usr/share/edk2/ovmf/UefiShell.iso \ --ovmf-template-vars /usr/share/edk2/ovmf/OVMF_VARS.fd \ --fedora-version 27 \ --kernel-path /tmp/qosb.kernel \ --kernel-url https://download.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/images/pxeboot/vmlinuz \ --initrd-path /tmp/qosb.initrd \ --initrd-url https://download.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/images/pxeboot/initrd.img \ another-output-VARS.fd
This script does the following, in that order:
(1) Launches a QEMU guest with the UefiShell.iso as a CD-ROM.
(2) Automatically enrolls the cryptographic keys in the UEFI shell.
(3) Finally, downloads a Fedora Kernel and 'initrd' file and boots into it, & confirms Secure Boot is really applied.
Alternatively: You can also verify that Secure Boot is enabled properly
in a full virtual machine by explicitly running
dmesg, and grepping
for "secure" string. On a recent Fedora QEMU+KVM virtual machine, it
looks as follows:
(fedora-vm)$ dmesg | grep -i secure [ 0.000000] Secure boot enabled and kernel locked down [ 3.261277] EFI: Loaded cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to '.builtin_trusted_keys'
What certificates and keys are enrolled?
The following certificates and keys are enrolled by the tool:
As Platform Key, and as one of the two Key Exchange Keys that we set up, the
EnrollDefaultKeys.efibinary on both Fedora and RHEL, uses the same digital certificate called
Red Hat Secure Boot (PK/KEK key 1)/emailAddressemail@example.com, and Red Hat's Product Security team has the private key for it.
The certificate that is enrolled as the second Key Exchange Key is called
Microsoft Corporation KEK CA 2011. Updates to the authenticated dbx (basically, "blacklist") variable, periodically released at http://www.uefi.org/revocationlistfile , are signed such that the signature chain ends in this certificate. The update can be installed in the guest Linux OS with the
Then, the authenticated
dbvariable gets the following two cetificates:
Microsoft Windows Production PCA 2011(for accepting Windows 8, Windows Server 2012 R2, etc boot loaders), and
Microsoft Corporation UEFI CA 2011(for verifying the
shimbinary, and PCI expansion ROMs).