Have you enabled Secure Boot on your computer? I sure have, but what is it and why it’s so important to the fabric of computing today? Why is Windows 11 pushing Secure Boot so hard? Is it a way for Microsoft to block off third party operating systems? Did someone on a forum or Discord tell you to turn it off? All of this and more as we learn together why UEFI Secure Boot should be required for everyone!
What is UEFI?
Desktop computing is exposed to constant threats in the wild and one of the worst things that could be compromised is your boot process. For something like your phone or your laptop with critical information, we want that stuff locked down tight to prevent bad guys from getting in.
In a brief (ultra-simplified) explainer, any computerized has 3 major layers:
- Your hardware, like the device you use.
- Your BIOS, which operates as a single point of trust to handle things like peripherals.
- Your operating system, like Windows, macOS, or Linux, where you make changes to your computer.
While booting up a computer started off simple in the early days, it has become more complex. Previous older iterations were things like the Extensible Firmware Interfaces (EFI), which is a miniature operating system that vastly increased this capability. EFI adds that ugly interface you have hidden away that controls things like your power management, virtualization, and what not.
UEFI “unifies” the complexity of EFI, but also makes UEFI the “trusted” version of EFI. You rely on your firmware to know if your computer is properly booting and not doing something sketchy in the process. UEFI is another chip attached to your motherboard that adds cryptographic authentication your devices are running and initialized properly. We need UEFI because many corporations view UEFI as the continuation and future of EFI.
What is Secure Boot?
The added cryptographic verification presented a new frontier for device makers. Personal computing devices like your computer or your phone contain lucrative information for attackers, so the big operating system vendors invest into protecting the sanctity of your system.
This started with the Platform Initialization standard. This generates a key, typically from your motherboard’s manufacturer, which attests the firmware on your motherboard is indeed valid and has not been tampered with (there’s protections for timestamping changes, so modifications, to prevent rollbacks, and replay attacks).
Secure Boot uses UEFI’s keys and ties it to pre-baked keys from your manufacturer to add an extra layer of security against malware exploiting this boot process (it’s similar to the prebuilt keys in your browser). This validates that the operating system you boot up is precisely the intended target and there’s no malicious code burrowed in as your device boots up. There’s also a keystore with forbidden keys, where if a key can no longer be used to verify boot images, it’s added to a blacklist so they won’t ever work again.
Exploitable Firmware Interfaces
This isn’t hypothetical, because state-sponsored attacks and limited attacks in the wild take advantage of people who haven’t caught up yet despite the years that have gone on. The Chinese research company Qihoo 360 reported on (in Chinese) UEFI rootkits using the backwards compatibility modules for EFI in ASUS’s computers.
Most recently, the Russian firm Kaspersky found a rootkit yet another vulnerability targeting this backwards compatbility, once again in ASUS and Gigabyte motherboards. If you thought ASUS shorting their BIOS or Gigabyte getting their firmware backdoored, that isn’t even the worst of it!
Microsoft Vs Corporate Linux
These sophisticated attacks are nothing compared to the history tied into the way Secure Boot was presented to the public. The dreaded operating system Windows 8, under the iron fist of Steven Sinofsky, began to require “Microsoft-compliant” UEFI Secure Boot. In the classic, poorly worded style of Microsft communication from the madman, Sinofsky added just a little clause to these requirements:
In the screenshot below you will notice that we designed the firmware to allow the customer to disable secure boot. However, doing so comes at your own risk. OEMs are free to choose how to enable this support and can further customize the parameters as described above in an effort to deliver unique value propositions to their customers.
This last line got major Linux manufacturers seriously concerned because history has shown OEMs often cut corners to ship firmware and what if the ability to boot something other than Windows was taken away?
Papers from Red Hat and Canonical describe how the ability to write and add keys needed to be included into the Microsoft requirements so OEM keys. In the original Build blog post, Sinofsky does mention this at the beginning, contradicting the quote that got everyone so worried:
Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components… Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows
This quote provides probably the “intended” (whatever that means to you) meaning to users, “you can turn off Secure Boot, but you do so at your risk.” If you examine these carefully, you’ll see Red Hat and Canonical’s engineers don’t reject the UEFI or Secure Boot standard, but it needed to be done in an inclusive way to allow Linux users, on the server or desktop, to get Secure Boot.
Secure Your Boots Now!
To this day in comments, in places like Reddit, Discord, or 4chan, I continue to hear is using Secure Boot doesn’t work if you don’t use Windows. And while that might have been true at one point, it hasn’t been true for over a decade. I can guarantee that the vast majority of Linux users disabled Secure Boot because a guide online told them to. For example, I caught this “guide” from some guys on the Garuda Linux team telling their users to disable Secure Boot, which just borders on irresponsible because it can be done!
Not just this behavior, but also the fact Garuda automatically trusts and rebuilds some goofy fork of the AUR is reason alone you should just stay away from them.
It’s even more ironic the 2 most popular desktop Linux distributions, Fedora and Ubuntu (and their derivatives like Mint and ublue for example), have never been subject to this. Red Hat and Canonical have to cough up a one-time $99 fee to access the 3rd party Microsoft key, which ensures their users get full access to Secure Boot. This third party shim key Fedora pays for is used by the USB tool Ventoy to ensure Windows 11 and other compatible Linux distros can use Secure Boot out of the box (with a nifty guide!).
But Secure Boot on Linux breaks if you use the proprietary drivers like NVIDIA proprietary driver. In Fedora, Fedora includes Akmods, a startup script that rebuilds your packages on boot. Akmods allows you to generate your own key using openssl and sign the Linux kernel, thus allowing NVIDIA’s driver through Secure Boot correctly.
I wrote 2 little scripts based on a guide from the folks at Fedora’s RPMFusion that allows you to sign the kernel, so you too can get Secure Boot with the NVIDIA driver on Fedora. Once you enroll your keys, you reboot and can toggle some settings using mokutil to configure Secure Boot properly, by continuing with your keys. There are other methods for openSUSE’s installer and Arch Linux, but I’m not familiar enough with them.
I’m going to leave it there because instead of making strawman arguments claiming Secure Boot will lock people out, we need to accept the new standards because UEFI and Secure Boot are realities you need to wake up to. I didn’t even get into the part where Windows and Linux are just broken compared to Macs or mobile devices! So leave a like on this video. Leave a like on this video if you hated the Windows 8 era!
Verified Boot and TPM-verified boot
Desktop computing security is fundamentally broken compared to the strength of verified boot on Android and Apple devices. The advent of technologies like Intel Bootguard and Microsoft’s Pluton prove that the silver-lining of Windows 11 is PC verified boot has gotten easier than ever. However, there’s the issue of certificate verification. There’s are bypasses that require enabling third party UEFI certificates, like the ones Fedora and Ubuntu use, on Lenovo computers, but Linux now supports Secured Core computers without the need for such measures. If you use a distribution that isn’t a rolling release with an updated Linux 6.3 kernel or higher, you won’t get access to stuff like Pluton.