[UPDATE, with input from readers, see EOM. Thanks!]

UEFI Secure Boot is a build-time feature of UEFI that helps secure the boot process from some boot-time attacks, optionally using TPM hardware if available. Secure Boot became widespread on Windows hardware during Windows 8 timeframe. Windows aside, other operating systems have to support UEFI Secure Boot. Linux supports UEFI and UEFI Secure Boot (as does FreeBSD). Different Linux distributions have different Linux kernels, with different versions, different patchsets, and different build-time directives enabled. So, Fedora’s Linux kernel is different than SuSE’s Linux kernel, etc.

I saw a recent comment from a UEFI security researcher who had been building a Linux liveboot CD and running CHIPSEC — which includes a native Linux kernel driver, and running it on UEFI systems with Secure Boot enabled.

“Ubuntu appears to have shim and do secure boot but not enforce kernel module signing.”

This Ubuntu behaviour was a change in behaviour from the Fedora-based systems the researcher was used to using. I was curious about the difference in distros w/r/t enforcing kernel module signing. So I asked on the FirmWare TestSuite (FWTS) list if there was a test for this. Roderick W. Smith of Canonical — and author of rEFInd boot manager and the definitive Linux boot loader/manager reference on RodsBooks.com — replied clarifying the situation:

“Yes, that’s correct. Ubuntu’s kernel doesn’t attempt to enforce Secure Boot policy beyond the main kernel file; once the kernel’s loaded, it’s possible to load an unsigned kernel module. Fedora, as you inferred, does require signing of kernel modules. Fedora’s approach is arguably more secure, since an attacker can’t load a malicious kernel module once the system has booted, but leads to problems with third-party kernel modules, like the in-kernel portions of nVidia and ATI/AMD video drivers. FWIW, the decision to do it this way was made before I joined Canonical, so I’m not sure who made the decision.”

Ivan of Canonical replied with more information:

“On Linux, two stage booting has implemented for secureboot. First stage is firmware boot to shim and then shim will take care to check signature and boot with grub and kernel. Booting with/without kernel signed is under shim and grub implementation, Ubuntu provides the singed kernel in official releases, and would like to keep the flexibility for user to build their kernel, so Ubuntu doesn’t block booting when user uses unsigned kernel.”

The security researcher who reported this speculated that Canonical’s policy may be due to them not wanting to put their distro signature (or perhaps worry about license issues in doing so) on some 3rd party (non open) binary.

As I understand things, this is beyond the strict “UEFI Secure Boot” definition, and on to what OS-centric post-UEFI Secure Boot security techniques it will implement. I guess some call it “OS Secure Boot” to differentiate it from “UEFI Secure Boot”, but I don’t see any formal definition for that term.

I wish there was more precise information about Secure Boot implementation from each Linux distro. System administrators and technical support engineers will need to know these nuances, as will security researchers. Pehaps Linux Foundation or UEFI Forum — or some Wikipedian(s) — could help with a comparison of Secure Boot on different OSes? Perhaps FWTS or CHIPSEC could have a test to check? Perhaps the UEFI Forum could note these nuances at their next plugfest, and setup test cases combinining Linux OSVs with a test case that loads dynamically load native OS drivers: perhaps using CHIPSEC as the test case may suffice, it loads a native helper driver.

So, don’t just look at if Secure Boot is enabled or not, look at what Linux OS you’re using, and how it implements Secure Boot. And remember attackers are also making this choice, and looking for your softer Linux targets, so be more careful when using those systems.

——-

Updated information:

The reason this issue came up is that the researcher was using Intel CHIPSEC, which when run on Linux it uses a Linux kernel module. Unlike most drivers, which get loaded when OS initializes, then stay loaded, the CHIPSEC driver behaves differently. The CHIPSEC userland Python app compiles the kernel module, and loads the module when it starts, then unloads the driver when it finishes (because the driver enables risky things, see it’s warning.txt). On Fedora, this kind of CHIPSEC driver loading behavior will not work, with Secure Boot enabled, until you setup moklist and sign the module. By contrast with Fedora, on Ubuntu, CHIPSEC is able to load the unsigned driver without the user having to change anything (convenience). Here’s more information on how Fedora does it’s module signing process:
http://docs.fedoraproject.org/en-US/Fedora/22/html/System_Administrators_Guide/sect-kernel-module-authentication.html