Ubuntu
grub2-signed package

Why aren't all the modules signed?

Asked by Shawn Rose

Hi, I was recently trying to use Grub as a signed variant of UEFI:NTFS (https://github.com/pbatard/uefi-ntfs), and mostly got it working: I got grub configured to boot the bootloader, and it almost totally worked out for me except for the problem that the NTFS module isn't actually signed, thus leading to Secure boot forbidding to load the module. I did a bit of digging, and sure enough none of the .mod files are actually signed, and so Secure Boot will refuse to load them. Looking into the past, it seems that a previous example of this (the gettext module) also had this problem, and the result was just compiling the module into the signed image (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1104627).

I know compiling the NTFS module into the main image is pointless, since 99% of people would never use it (I wouldn't even want it compiled into the standard image), but why aren't the modules themselves signed with the Canonical secure bootloader key (Or even signed with a special 'grub module' key with the public key embedded, similar to the microsoft-signed shim)? According to the #grub irc room on freenode grub supports loading signed modules, so it stands to reason that you could simply have all the modules signed for full secure boot support, even with modules that aren't included in the stock signed image.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu grub2-signed Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

Disable secure boot may be a solution.....

Revision history for this message
Shawn Rose (shawnandrewrose) said : 		#2

Disabling secure boot is more of a workaround than a fix to be honest. For example, in my use case I plan on using it for a repair stick of sorts, so having to disable secure boot is an extra reboot (or two in some cases) in addition to modifying bios settings which I would likely have to revert after I'm done.

Revision history for this message
Jeremy (wa113y3s) said : 		#3

A boot loader would need a special signing key. I read that the Grub bootloader that the Ubuntu install uses was signed by Microsoft but I don't know if I can ever believe it

Revision history for this message
Shawn Rose (shawnandrewrose) said : 		#4

Actually, the way Ubuntu does it is twofold: The grub bootloader is signed by a Canonical signing key (Specifically, the common name is "Canonical Ltd. Secure Boot Signing"), and they have a signed 'shim' which is signed by Microsoft's UEFI key (bootx64.efi) which loads grub. The way it's set up tells the secure boot system to allow the Canonical signing key, letting there be a full chain all the way.

This essentially means that Canonical (and thus the grub2-signed project) has access to a key which can be used to sign EFI binaries for secure boot, and thus it stands to reason that all grub modules can and should be signed with it at the same time as the main grub binary. I'd also like to note that the fwupdate-signed package's 'fwupx64.efi' binary is signed by the same key as the grub project, so there shouldn't be any 'we can only sign this one specific binary with this key' rules.

Revision history for this message
Best Colin Watson (cjwatson) said : 		#5

The mechanism used for module signing in GRUB postdates us setting up image signing for UEFI Secure Boot, and we've never got round to working out how the two might interact. (For instance, they use entirely different key formats.) This also means that we can confine the set of GRUB modules that could cause a Secure Boot compromise to a smaller set. You can certainly raise bugs asking for additional modules to be added.

Revision history for this message
Shawn Rose (shawnandrewrose) said : 		#6

Thanks Colin Watson, that solved my question.