MJG's signed Shim for UEFI Secure Boot now available

Question

There have been a number of posts about EFI and Secure Boot recently, so I thought some people might be interested in this:
http://mjg59.dreamwidth.org/20303.html
That's Matthew Garrett's announcement of a signed binary version of his Shim boot loader. Basically, this program will boot on a computer with Secure Boot active in its default mode (with Microsoft's keys in the firmware) and then launch another boot loader (called grubx64.efi, although it could be something other than GRUB in that filename) that you sign with your keys. The end result is something that's more secure than disabling Secure Boot entirely and easier than installing your own Secure Boot keys. I haven't yet tried this version of the binary, so I can't provide help beyond pointing you to MJG's own blog, but I thought some people might want to know about it.
FWIW, although you could sign and launch my rEFInd boot manager with this version of Shim, the current version (0.4.7) won't be very useful when signed in this way, since it doesn't yet "talk" to Shim. I'm working on changing that, so that rEFInd will launch binaries signed in a way that Shim supports.

Answer 1

kristof wrote:A signed bootloader is nice, but unless the Arch developers start distributing a version of the kernel that's also signed with a MOK, secure boot isn't being fully utilized.
Largely true, but:
Secure Boot is here, and seems likely to stay. Given this fact, all Linux distributions (including Arch) need a way to cope with it. There are basically two choices: Provide instructions on how to deal with it (difficult because of system-to-system differences) or provide signed binaries (a boot loader at a minimum, or preferably a boot loader and kernel).
It's possible to "provide" a signed binary by generating the key locally and signing it locally. This could be done by scripts in the installation process, for example. Of course, that still leaves a need to get the installer booted on a Secure Boot system, but that could be handled with the Linux Foundation's pre-bootloader.
To be truly effective, Secure Boot really requires support all the way up the software chain. Signing a kernel does no good if the kernel can load unsigned modules, for instance. Fedora's taking steps to provide such security, but Ubuntu seems to be going with a more relaxed approach. In truth, Linux isn't as bothered by malware as is Linux, so it's unclear that going with a Fedora-esque approach is really helpful; but OTOH, it's conceivable that malware authors will start using Linux as a vector to install boot-time malware if Windows becomes sufficiently locked down, so maybe some paranoia is in order.
At the moment and as a practical matter, technical Linux users (including most Arch users) will find it quicker and easier to disable Secure Boot than to use shim. As shim and various support tools (signing utilities, boot managers, etc.) mature, though, this may not be the case. It may also be desirable or even necessary to leave Secure Boot enabled, in which case adopting shim now may make sense. Likewise if you want to learn about it now so that you can use it in the future.