Is there a way to tell whether my EFI bootloader would accept the signature of the binary without reboot?

Question

Assume that I have just installed a signed EFI bootloader (e.g. grub2 from Ubuntu 14.10 amd64 on a Lenovo IdeaPad U410 which can only boot in secure boot EFI or legacy mode) on a machine from within a Linux or (more specified) Debian based system. Is there a way to tell the machine would boot from within the running without rebooting?

Answer 1

Yes, but you must have your Secure Boot keys in hand. First, be aware that there are at least three forms that Secure Boot public keys may take:

• .cer/.der files -- These files are used by most UEFI implementations, as well as by the MokManager tool that's paired with Shim.
• .crt -- These files are used natively by most Linux security tools, such as sbsigntool and sbverify.
• .esl -- These files combine multiple keys into one file. (The other files each contain a single key.) If you use a firmware user interface or KeyTool to save your keys, the resulting files will be in this format.

If you've installed your own Machine Owner Key (MOK) using MokManager, you should have the file in .cer/.der form. If you want to test whether the binary will work when booted with another key (such as the keys used to sign Ubuntu's or Fedora's version of GRUB), you'll have to obtain it. For convenience, I've collected several with rEFInd; you can download them piecemeal here. If you've taken full control of Secure Boot on your system, you should also already have the keys you created.

To verify a binary, you must have a key in .crt form. If you've got a key in .der or .cer form, you can convert it:

openssl x509 -in mykey.cer -inform der -out mykey.crt

Then, you can check that the binary is properly signed:

sbverify --cert mykey.crt binary.efi

The result should be a message reading Signature verification OK or Signature verification failed.

Note that some UEFIs fail to launch even properly-signed binaries. This appears to be random; Binary A will launch OK, whereas Binary B, signed with the same key, fails. I believe this is a bug in the affected UEFIs, but I've not investigated it in detail. AFAIK, it doesn't affect binaries verified via Shim, but it can affect Shim itself or binaries launched without the help of Shim.