rhuefi / qemu-ovmf-secureboot Goto Github PK

The term "VARS" is a contraction for "VARiableS".

Current we use "vars file", or just "vars" in the texts, source and commit messages. Maybe it's nicer to stay consistent and use: "VARS file" or "OVMF VARS file".

As even the EDK2 RPM itself uses "VARS" in the file names

$> rpm -ql edk2.git-ovmf-x64-0-20180109.b3261.g427b2f41a6.noarch | grep VARS
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-need-smm.fd
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-with-csm.fd

EnrollDefaultKeys.efi currently hardwires the X509 certificate that is enrolled as Platform Key and first Key Exchange Key:

"Red Hat Secure Boot (PK/KEK key 1)/[email protected]"
SHA1: fd:fc:7f:3c:7e:f3:e0:57:76:ad:d7:98:78:21:6c:9b:e0:e1:95:97

This certificate should be taken from a regular file on the build host however, and passed to EnrollDefaultKeys.efi through the QEMU command line.

That will allow GNU/Linux distros to easily customize the Platform Key / first Key Exchange Key in their OVMF_VARS.secboot.fd (or equivalent) varstore template files -- a distro typically wants their own security team to generate that certificate.

Please refer to the following pre-requisite tickets:

• QEMU: https://bugs.launchpad.net/qemu/+bug/1826200
• edk2: https://bugzilla.tianocore.org/show_bug.cgi?id=1747

Thanks!

The current verification step downloads the Fedora 27 kernel and checks if it executes when Secure Boot is on.
Such kernel is signed with a Red Hat KEK (CN = "Fedora Secure Boot Signer").

Instead, the test should check that a kernel signed with the input key (whose certificate is passed with --oem-string) runs, because the purpose of EnrollDefaultKeys.efi is to set PK and the first KEK with the user's key.

As a matter of fact, I am a bit surprised that the Fedora 27 kernel (signed by Red Hat) boots at all.
That should not be happening, right? For the record, I am using EnrollDefaultKeys.efi from Fedora 33.

For both enrollment and verification, we should have a timeout (configurable), so that we don't just hang forever if something went wrong, but rather just error out.

We should add a hidden argument to not actually perform the enrollment, and make CI test that if we pass that, we error out.
This would make sure the enrollment test also fails gracefully.

I feel like I'm being robbed of some interesting verbose messages. Let's add those!

Right now, we start writing to the destination file immediately, which means that if something went wrong, we are left with an unconfigured vars file.
We should make sure to only move the file there after it is finished.
Probably we should use a temporary file until done.

Right now, we may stay around if QEMU stays around after an error (e.g. using acceleration in a situation you can't).
We should correctly detect this and abort, making sure to terminate qemu.