Matthew Garrett, a well-known Linux kernel developer who once received an award from the Free Software Foundation for his contributions to open-source software, explained the essence of the SBAT (Secure Boot Advanced Targeting) mechanism, created to block vulnerabilities in the bootloader without revoking digital signatures, as well as its role in the recent incident involving an update for Windows that led to the failure of some Linux distributions to boot when installed alongside Windows on systems with UEFI Secure Boot enabled. In short, both Microsoft, which didn't fully test the update and applied it to systems it shouldn't have, and the developers of some Linux distributions, who didn't update the GRUB bootloader or SBAT generation number when vulnerabilities were found in GRUB, share the blame. <\/p>\n
Below is a translation of Garrett's note: <\/p>\n
\nWhen the UEFI Secure Boot specification was being developed, all participants were, let's say, a bit naive. The main security model of Secure Boot is that all code that runs in a privileged environment at the kernel level must be verified before execution \u2014 the firmware verifies the bootloader, the bootloader verifies the kernel, and the kernel verifies any additional code loaded at runtime. Now we have a trusted environment to enforce any other security policy we want. Clearly, people can make mistakes, but the specification includes a way to revoke signed components that have proven to be untrustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash, even if it is signed by a trusted key. <\/p>\n
Unfortunately, it turns out that the problem lies in scale. Every Linux distribution operating within the Secure Boot ecosystem generates its own bootloader binaries, each with its own hash. If a vulnerability is discovered in the source code of such a bootloader, it necessitates revoking a large number of different binaries. The memory allocated for storing the variable containing all these hashes is limited. There simply isn\u2019t enough space to keep adding a new set of hashes every time it turns out that GRUB (the bootloader originally written at a time when boot protection was not practiced, and which has several separate parsers for image files and font files) has yet another mechanism for an attacker to execute arbitrary code, which is why a different solution was required. <\/p>\n
This solution is called SBAT. The overall concept of SBAT is quite simple. Each important component in the boot chain declares a security generation, which is included in the signed binary file. When a vulnerability is found and fixed, this generation is incremented. Then an update can be issued that specifies the minimum generation \u2014 boot component will look at the next item in the chain, compare its name and generation number with those stored in the firmware variable, and decide whether to execute it based on that. Instead of revoking a large number of individual hashes, one update can be released that simply says, 'Any version of GRUB with a security generation below this number is considered untrusted.' <\/p>\n
So why has this suddenly become relevant? SBAT was developed jointly by the Linux community and Microsoft, and Microsoft decided to release an update for Windows that instructed systems not to trust versions of GRUB with a security generation below a certain level. This was done because these versions of GRUB had real security vulnerabilities that allowed attackers to break the secure boot chain of Windows, and we have seen real examples of malware attempting to do this (Black Lotus exploited a vulnerability in the Windows bootloader, but the vulnerability in GRUB was just as effective). From a purely security perspective, this is a perfectly legitimate desire. <\/p>\n
Now, regarding the message 'Something went completely wrong' and the inability to boot as a result of this update. It is output by shim, not any code from Microsoft. Shim takes SBAT updates into account, and in order not to violate the security principles adopted by other bootloaders in the system, even though Microsoft released an SBAT update, it is actually the Linux bootloader that refuses to launch older versions of GRUB. Everything works as it should. <\/p>\n
The problem people faced is that several Linux distributions did not release GRUB versions with the newer security generation, and thus these GRUB versions are considered insecure (it's worth noting that GRUB is signed by the distributions themselves, not Microsoft, so there is no external lag here). In Microsoft's design, the Windows Update was supposed to apply the SBAT update only to systems running solely Windows, while any dual-boot installations would remain vulnerable to attacks until the installed distribution updated GRUB and upgraded the SBAT generation. Unfortunately, as is now clear, this did not work as intended, and at least some dual-boot systems applied the update, while the shim of that distribution refused to load that distribution's GRUB. <\/p>\n
What is the outcome? Microsoft (for understandable reasons) did not want Windows to be attackable via a vulnerable version of GRUB that could be deceived into executing arbitrary code and then implanting a bootkit into the Windows kernel during boot. Microsoft accomplished this by releasing a Windows update that updated the SBAT variable, indicating that vulnerable versions of GRUB should not be booted on these systems. The first-stage bootloader provided by the distribution read this variable, read the SBAT partition from the installed version of GRUB, realized they conflicted, and refused to load grub with the message 'Something went completely wrong.' This update was not intended to apply to dual-boot systems, but it still did. <\/p>\n
In summary: <\/p>\n
1) Microsoft applied the update to systems that it should not have been applied to. <\/p>\n
2) Some Linux distributions did not update the GRUB bootloader and the SBAT security generation when vulnerabilities were found in GRUB. <\/p>\n
As a result, some people are unable to boot their systems. I believe there are many parties at fault here. Microsoft should have conducted more testing to ensure that dual-boot installations could be accurately recognized. However, distributions providing signed bootloaders must ensure they update them and keep security generations current, because otherwise they provide an attack vector that can be used to compromise other operating systems, which is a kind of violation of the social contract surrounding all of this. <\/p>\n
Unfortunately, the victims here are primarily end-users who find that their system suddenly refuses to boot the OS they wish to load. This should never happen. I don't believe that polling end-users about whether they want secure boot updates will yield a good outcome, and while I vaguely lean towards the view that UEFI secure boot is not something that benefits most end-users, it is also something you don't want to discover after incidents like this, so I sympathize with it being enabled by default; hence, I support its default enablement and share Microsoft's choice, except for the failed attempt to avoid updates on dual-boot systems. <\/p>\n
In any case, I was heavily involved in implementing this mechanism for Linux back in 2012 and wrote the first prototype of Shim (which is now a significantly better bootloader supported by a wider range of people, and which I haven't touched in several years), so if you want to blame someone, please feel free to blame me. This is not something that should have happened, and if you're not Microsoft or a Linux distribution, it's not your fault. I apologize. <\/p><\/blockquote>\n