With news like this, cited by Bruce Schneier (1), people are wondering if it is worth using Secure Boot.

As for the specific news article, this is always a risk with distributed public key encryption systems. Lose control of a single private key and attackers can do bad things. That doesn’t make it bad, it just makes it less valuable. If you want to set up a system for a government agency, bank, or other high-value target, it’s reasonable to expect an adversary to buy systems of the same make and model to verify that their attacks will work. If you want to make your home PC a little harder to attack, you can expect that likely adversaries won’t bother with such things. You don’t have to have perfect security, making one attack slightly harder than other potential attacks gives you a big chunk of the advantage.

The purpose of Secure Boot is to verify the bootloader with a public key signature, and then have the bootloader verify the kernel. Microsoft signs the “shim” that every Linux distribution uses to load GRUB (or some other bootloader). So when I configure a Debian system with Secure Boot enabled, it doesn’t stop anyone from booting Ubuntu. From the signatures on the bootloader, etc., there is no difference between my Debian installation and a rescue image of Debian, Ubuntu, or some other distribution that has been booted by a hostile party to do things against my interests. The difference between a legitimate OS image and malware is a matter of who is booting it and the reason for booting it.

It is possible to disable Microsoft keys from UEFI to boot only from your own key. This document describes what is needed to do this (2). In principle, you can disable MS keys if you boot without using “option ROMs” (which means, among other things, your video card ROM).

Just because it is impossible to disable MS keys does not mean it is impossible to take advantage of the Secure Boot process. You can use a block device decryption process which includes a signature from the kernel and BIOS that is used as part of the decryption for the device. So if a system boots with the wrong kernel and the user does not recognize it, they will find that they are unable to unlock the device with the password. I believe it is possible on some systems to run the Secure Boot functionality in a non-enforcing mode, so that it uses a bootloader without a valid signature, but still uses the hash for TPM calculations. This seems impossible on my Thinkpad Yoga Gen3 which only has enabled and disabled as options, but should work on Dell laptops that have an option to run Secure Boot in permissive mode.

I believe the future is to use something like EFIStub(3) to create unified kernel images with a signed kernel, initrd, and command line parameters in a single bundle that can be loaded directly by the UEFI BIOS. From a distribution developer’s perspective, it’s good that many people are using the current standard functionality of shim and GRUB for EFI as a step toward that goal.

CloudFlare has a good blog post on Linux kernel hardening (4) . In that post they discuss the benefits of a full secure boot setup (which is currently difficult) and how secure boot enables the lockdown module for kernel integrity. When Secure Boot is detected by the kernel it automatically enables lockdown=integrity functionality (see this blog post for an explanation of lockdown (5) ). It is possible to enable this by setting “lockdown=integrity” on the kernel command line or “lockdown=confidentiality” if you want even more protection, but it is done by default with Secure Boot. Secure Boot is something you can configure to enable a selection of security features and get a known minimum level of integrity even if the signatures aren’t used for anything useful, restricting a system to only boot kernels from MS, Debian, Ubuntu, Red Hat, etc. is not useful.

For most users I think Secure Boot is a small increase in security, but testing it on a large number of systems increases the overall security of operating systems, which is a good thing for the world. I also think that having features like EFIStub that are usable by a large percentage of users (possibly the majority of users) is something that can be expected in the lifespan of hardware purchased today. So making sure that Secure Boot works with GRUB now will make EFIStub etc. easier to use in the future.

The Secure Boot page on the Debian wiki is worth reading and also updating for those willing to contribute (6).