6

I'm playing with GRUB2, SecureBoot and Kernel Signing and I think I found a possible bug in my Secure Boot, but I want to check my understanding of these processes first.

I know that when Secure Boot is enabled, only binaries signed with a Key loaded in the firmware can be launched, so all bootloaders have to be signed. In a typical case are shim and GRUB.

Shim should lunch the MoakManager if the boot fails or you have some keys to import or delete and if it's all right it should then launch GRUB which is the real bootloader.

The problem is that I've just generated a custom version of GRUB with grub-mkstandalone which I signed with a new key created with OpenSSl; a key I've not imported yet in the firmware, and shim was able to launch it without any reports from Secure Boot.

I checked the keys with mokutil --list-enrolled and it reported only the Canonical Certificate.


So, to recap:

In my EFI partition I have:

  • shimx64.efi signed by Canonical, generated with grub-install
  • my custom GRUB, generated with grub-mkstandalone, signed with my own key, wich I've not imported yet, named grubx64.efi.

At boot SHIM could lunch GRUB and GRUB could boot Ubuntu successfully.

If some Secure Boot check only the sign of the first bootloader and the others loaders are responsable for verifying theirself and the modules they preload and users eventually load, the security concern here is really high.

I'll do some more tests, but maybe I should open a bug ticket.


Any ideas?

Improve this question

1 Answer 1

Reset to default
4

I believe your understanding is correct, except that shimx64.efi is delivered in binary form via a package, not generated locally via grub-install. (grub-install is likely to install shimx64.efi to the ESP, though.) Oh, and it's MokManager, not MoakManager.

Before you file a bug report, you should retrace your steps and be 100% sure that you're booting via your locally-compiled GRUB. It's easy to accidentally put a binary in the wrong location or neglect to run efibootmgr to adjust the boot order, for instance. (You haven't described how you're installing your custom grubx64.efi -- are you overwriting the standard Ubuntu binary or putting your new one elsewhere and registering it [and a copy of Shim] via efibootmgr?) You might want to run sudo efibootmgr -v to see your boot details. Pay attention to the BootOrder and BootCurrent lines -- the former tells you the order in which boot options will be tried and the latter shows the option that was used to boot the computer. You'll need to cross-reference the numbers with the various Boot#### lines that describe each boot option. If you installed your own GRUB separate from Ubuntu's GRUB, it's conceivable that the firmware silently bypassed it because of a Secure Boot error and then fell back on the stock Ubuntu Shim/GRUB, which would explain what you're seeing.

Another possibility is that Secure Boot is not actually enabled on your computer. You can check this possibility as follows:

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 
0000000 0016 0000 0001              
0000005

In this example, the first line of output (0000000 0016 0000 0001) ends in a 1. This indicates that Secure Boot is active. If it ends in a 0, then Secure Boot is disabled on your computer.

One other possibility is that you might have somehow installed your local key in the firmware's own db list. This is a difficult task, though, so it's unlikely you've done it accidentally and without realizing it. (See my page on the subject for details on how to set this up.) I mention this possibility mainly for the sake of completeness; it doesn't strike me as likely at all unless you're omitting mention of a previous attempt at mastering Secure Boot in this way.

If you are seeing a bug, it could be in either Shim or in your firmware.

One more caveat is that I'm only passingly familiar with GRUB-specific tools such as grub-mkstandalone. As I maintain rEFInd, I prefer to use it, so my knowledge of GRUB tools isn't as in-depth as it might be. Thus, I might be missing some critical detail because it's GRUB-specific.

Improve this answer
4
  • You're right, I've disabled the option during my numerous tests, I stil don't believe it.
    – JumpAlways
    Jan 24, 2017 at 10:21
  • There's another strange behaviour now, the boot shows boot succeded ubuntu and then the blue MokManager screen appears to tell me Verification Failed. Since I've changed only the GRUB, why the standard messagebox from Secure Boot doesn't appear instead?
    – JumpAlways
    Jan 24, 2017 at 10:26
  • I've seen you're quite an expert in this field, and I'd linke to ask you something else about bootloaders, how can I contact you?
    – JumpAlways
    Jan 27, 2017 at 4:16
  • If you're generating a custom grubx64.efi, either it must be signed or its hash enrolled for Shim to accept it. If you're seeing an error as you describe, my suspicion is that you've not enrolled the key or you did something wrong in the signing process. There are lots of other possible causes, though, like an improperly-signed kernel, a bug in Shim, a mistake in setting up the chain of binaries, etc. You can contact me at the address on my Web site, rodsbooks.com.
    – Rod Smith
    Feb 1, 2017 at 1:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .