I've found a lot of conflicting and confusing reports about the #SecureBoot issue caused by a Microsoft update, so here's my relatively informed take about it.
Spoilers: this isn't an issue with GRUB, but with another less known bootloader called shim. GRUB can also be affected though. So let's talk about how the bootchain of a #Linux distro works and what happened to it. 1/11
Mainstream Linux distros all support booting in a Secure Boot environment.
Secure Boot guarantees that all the code loaded at boot has been signed with a trusted key and all modern PCs ship with a preinstalled key owned by Microsoft. This key is used to sign Windows' bootloader, kernel and modules. 2/11
In order to boot Linux in a Secure Boot environment one would need to sign the bootloader and kernel with Microsoft key, something that is possible but expensive, cumbersome and impractical. The alternative would be to sign it with another key, and have users load it in their motherboard UEFI firmware, but this is even more impractical. So a compromise was made in the form of the shim bootloader. 3/11
shim is a minimal bootloader that has only one task: validating and loading another bootloader. This second bootloader will not be checked against the machine's primary Secure Boot key, but against a separate key loaded in what is called the Machine Owner Key list (MOK). This list allows for user-provided keys and - contrary to the machine's primary key - is relatively easy to access for a user. 4/11
shim itself is released seldomly, and every release is signed with Microsoft's key. So, every PC will trust it. Linux distros will ship it with their own distro key, and will sign GRUB and the Linux kernel with the latter. On first run, shim will ask the user to load the distro key in the MOK. From this point on shim will trust all the bootloaders signed with this key. 5/11
To recap, the boot chain looks like this: the motherboard's UEFI firmware loads shim, it checks it against Microsoft's key, then runs it. shim loads GRUB, checks its signature against the keys in the MOK and if one matches runs it. GRUB will further check the kernel's signature against the keys in the MOK before running it and so on. Every step of the boot process needs to happen via an executable that is signed with a trusted key, starting with Microsoft's. 6/11
So far so good, but here's the thing: what happens if a bootloader has a serious security issue? We wouldn't want to load it, even if it's signed with a trusted key. The way to implement this mechanism is the Secure Boot Advanced Targeting revocation list (SBAT). This is a list of bootloader versions that have been revoked, i.e. they're not trusted anymore and should never be booted, even if they're correctly signed. 7/11
SBAT has its own idea of what a bootloader version is. Every bootloader is associated with an integer number that is only updated when an old version needs to be revoked. So for example the SBAT version of shim 15.6 is 2. shim version 15.7 has a SBAT version of 3 and finally 15.8 is 4. And here lies the problem: the SBAT list can be updated independently of the bootloader and that's exactly what Microsoft did. 8/11
Microsoft's SBAT update contains the following entries:
sbat,1,2024010900
shim,4
grub,3
grub.debian,4
You probably already spotted the problem: GRUB versions older than '3' are revoked, but so are shim versions older than '4'.
When an old shim version runs, it will check its SBAT version against the SBAT revocation list, and find that it has been revoked. That's why the error message says that the *SBAT self-check* failed. 9/11
It's not a problem with GRUB, though older versions of GRUB are also affected, it's mainly a problem with shim itself.
Newer Linux distros are shipping a version that is recent enough, and thus weren't affected, but older ones - including supported ones - must now ship an updated version of shim in order to keep working with Secure Boot. Updating shim is not complicated, but you need to boot first, which requires deleting the revokation list, or disabling Secure Boot altogether. 10/11
Overall this is a huge mess. Secure Boot itself is not excessively complex - though it has a few moving parts some of which are not to my liking - but the combination of this complexity, Microsoft's de-facto monopoly and the inability to easily deploy user-provided keys made it a much bigger mess than it should have been. 11/11
@gabrielesvelto There was also nothing stopping MS from doing the right thing and version bumping the shim if it was installed.
@gabrielesvelto Nice write up.
What was Microsoft's intent with the update? Grub was the component with the CVE, so why include shim in the revocation?
@shenki old shim versions also solved some security issues, so maybe they figured they'd revoke all the old stuff in one sweep. Alternatively it was a genuine mistake and the shim part was added accidentally
@gabrielesvelto @shenki I digged a bit trying to find out which generation number matches which grub version and while I wasn't successful I found the document https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt and I guess they just copy and pasted the most recent entry from there.
@gabrielesvelto
Thanks for the detailed writeup.
I am just confused by one thing: According to your list should shim 15.8 be fine. But Ubuntu 24.04 is shipping that version according to https://packages.ubuntu.com/search?keywords=shim so any idea what went wrong there?