{{Header}}
{{#seo:
|description=Complexities and security concerns of Secure Boot in the context of Linux distributions. The challenges posed by Secure Boot's requirement for a single signature on binaries, the reliance on Microsoft's key for booting, and the implications for user trust and security. 
}}
{{boot_firmware}}
{{intro|
Complexities and security concerns of Secure Boot in the context of Linux distributions. The challenges posed by Secure Boot's requirement for a single signature on binaries, the reliance on Microsoft's key for booting, and the implications for user trust and security. 
}}
{{stub}}
= Bad Design =
Single point of failure master signing key in all motherboards.

* [https://www.zdnet.com/article/microsoft-secure-boot-key-debacle-causes-security-panic/ Microsoft leaked the SecureBoot signing key.]
* https://www.schneier.com/blog/archives/2022/12/leaked-signing-keys-are-being-used-to-sign-malware.html
* https://www.schneier.com/blog/archives/2023/08/microsoft-signing-key-stolen-by-chinese.html
* https://www.schneier.com/blog/archives/2023/03/blacklotus-malware-hijacks-windows-secure-boot-process.html

Removing Microsoft key and relying on distribution (such as Debian) key is difficult. Not something that most users can do, let alone are doing.

Signing binaries with user-provided key is even more difficult.

Secure Boot allowing only one signature on a binary creates a major mess.

{{quotation
|quote=1) Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary -- so Fedora's shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft's key, official Fedora will no longer boot, as long as Secure Boot is on.
|context=[https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation (FSF): Free Software Foundation recommendations for free operating system distributions considering Secure Boot]
}}

Note: Unspecific to Fedora and also applicable to other Linux distributions.

{{quotation
|quote=1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware.
}}

But that does not help Ubuntu much because Ubuntu cannot sign its bootloader (shim) with both keys, the Microsoft key and their Ubuntu key. Therefore, quote:

{{quotation
|quote=2) Ubuntu CDs, distributed separately from hardware, will also depend on the presence of Microsoft's key in the machine's firmware to boot, when Secure Boot is active.
}}

And also the security gain is negligible because Microsoft's key also must be installed.

{{quotation
|quote=1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware. Additionally, they will be required by the certification guidelines to have the Microsoft key installed.
}}

The decision to either trust Microsoft or Ubuntu is a big one. But in rather rare cases it will make sense for users to trust both keys at the same time (except in dual-boot scenarios).

= Security Theater =
It is also a bit of security theater.

{{quotation
|quote=the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel.
|context=[https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html UEFI Secure Boot and Ubuntu - implementation]
}}

TODO: ExitBootServices

Then also nowadays the initial ramdisk used by most (if not all) Linux desktop distributions contains unsigned code.

At time of writing:

{{quotation
|quote=If you ask me, the status quo of UEFI SecureBoot code signing in the major Linux distributions is pretty sad. The work to get stuff signed is massive, but in effect it delivers very little in return: because initrds are entirely unprotected, and reside on partitions lacking any form of cryptographic integrity protection any attacker can trivially easily modify the boot process of any such Linux system and freely collected FDE passphrases entered. There's little value in signing the boot loader and kernel in a complex bureaucracy if it then happily loads entirely unprotected code that processes the actually relevant security credentials: the FDE keys.
|context=https://0pointer.net/blog/fitting-everything-together.html
}}

= Microsoft =
Microsoft is dictating policy for the Linux boot process.

{{quotation
|quote=Due to the complexity of the Linux boot process, the number of active releases from different distributions with compatibility challenges, and the support and serviceability timelines of in-market products, a limited exception to the NX signing requirements has been granted. 

This limited exception is granted for shims serving in-market products.  This exception will be reviewed regularly, and once component versions are identified that meet the compatibility requirements, new shim signing requests for products targeting the identified components will no longer be exempt. Additionally, when shim functionality is developed to provide compatibility for older, non-compliant boot components, new shim signings will no longer be exempt.  

Please reach out to: uefisign@microsoft.com with any questions on this policy.
|context=[https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 NX Exception for SHIM Community]
}}

Related shim ticket linking to the same source [https://github.com/rhboot/shim/issues/615 Is 15.8 being prepared?].

https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916

https://techcommunity.microsoft.com/t5/windows-hardware-certification/pre-submission-testing-for-uefi-submissions/ba-p/364829

= There is no single one shim =
There is no "THE shim". Each Linux distribution can compile its own. It is not very useful without getting signed with a key approved by Microsoft. To get reviewed, the shim review board is involved.

https://github.com/rhboot/shim-review

= efivars Storage Location =
Where is that UEFI boot entry stored? Inside <code>efivars</code> (a (U)EFI variable filesystem).

Where is <code>efivars</code> stored? Inside the <code>NVRAM</code>. What is the <code>NVRAM</code>? Imagine it being similar to a hard drive but not really a separate hard drive. It's a writable storage area on the motherboard, part of the firmware.

= Microsoft Secure Boot Signing Key Removal =

{{quotation
|quote=Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([https://en.wikipedia.org/wiki/Option_ROM OpROMs]), that get executed during boot, [https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Microsoft_Windows are signed using Microsoft 3rd Party UEFI CA certificate] or vendor certificates. This is the case in many [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X, P and T series laptops] which uses the Lenovo CA certificate to sign UEFI applications and firmwares.
|context=https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys
}}

= shim HTTP boot =
HTTP boot is part of the UEFI specification.

<code>shim</code> can be started from a UEFI boot entry. <ref>
https://github.com/rhboot/shim/issues/636#issuecomment-1938777413
</ref>

<code>shim</code>'s HTTP boot can then fetch and execute another UEFI executable such as bootloader (such as [[grub|GNU GRUB]] or [[Linux]]).

{{quotation
|quote=The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.
|context=[https://eclypsium.com/blog/the-real-shim-shady-how-cve-2023-40547-impacts-most-linux-systems/ The Real Shim Shady: How CVE-2023-40547 Impacts Most Linux Systems]
}}

related:

* shim bug report / feature request: [https://github.com/rhboot/shim/issues/636 remove shim HTTP boot due to security issues] / split shim into <code>shim-trivial</code> and <code>shim-http-boot</code>
* shim documentation pull request [https://github.com/rhboot/shim/pull/638 mention HTTP boot support in readme]

= Opinion =
Secure Boot is a mechanism imposed by Microsoft (Windows) designed to harm its competition, mostly Linux distributions. Its security properties are moot. Theory and practice. At time of writing:

* Secure Boot in theory: Real Open Source, Linux desktop distributions could have a full verified boot chain and might even have it one day, with user-controlled keys. Perhaps [[measured boot]] is more likely to materialize because multiple projects are working towards it. Example projects include systemd (<code>systemd-measure</code>) (see previous link, watch the linked videos) and [https://github.com/linuxboot/heads heads].
* Secure Boot in practice: Just causing user confusion, scaring users, usability issue, way too complicated to use, prevents users from using Linux distributions, causes issues with kernel module installation.

At time of writing, when using Real Open Source Linux desktop distributions, whatever changes on their local system regarding Secure Boot provide practically little relevant security benefit. The bootloader / kernel might be signed with one of the many keys signed by Microsoft, but anything later in the boot process remains unprotected.

Many keys signed by Microsoft: That is, unless the user is proactively studying Secure Boot, removing the Microsoft keys and deploying their own keys, which is a technically difficult process.

To protect the full system, that would be called "full verified boot."

There are no known Open Source Linux distributions working towards Secure Boot or full verified boot, except in so far that they aim to be compatible with a successful boot sequence without the user needing to modify BIOS settings. This is a usability feature and can be called Secure Boot compatibility.

Quote [https://madaidans-insecurities.github.io/guides/linux-hardening.html#verified-boot Madaidan's Insecurities, Linux Hardening Guide, Verified Boot]:

<blockquote>In general, it's hard to achieve a respectable verified boot implementation on traditional Linux.</blockquote>

This, at time of writing, can be translated to "users will with certainty be unable to achieve full verified boot on Real Open Source Linux desktop distributions."

There are no known developers of such distributions claiming that they have accomplished full verified boot, to the knowledge of the author.

To learn more, the user can read the [[Verified Boot]] wiki page, follow its links such as the excellent summary of developments [https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/ Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)], and watch the linked videos for [[measured boot]].

= See Also =
{{boot_firmware}}

= Footnotes=
<references/>
{{Footer}}
[[Category: Development]]