Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.
Can you explain the detailed reason why you think that? Voicing opinions is nice of course but explaining the thought process and logic is, I think, almost always more interesting to other people.
To start with, what do you think is the “normal users” threath model? And, for example, if one happens to be a member of any of the various minorities that authoritarian governments of every color happen to single out and persecute in your countries case, what would you want to protect from? Or if you are, say, a lawyer, and have a professional obligation to protect sensitive data from theft?
Actually, I would love for you to explain to me how Secure Boot alone would protect someone from any of that. If you want to protect files, you need full disk encryption, not Secure Boot.
Or are you seriously expecting a government-level threat actor to bother to:
That’s the great thing about fascist governments, is they have no need to be that sneaky. They can just change the laws to make whatever you’re doing illegal and jail you until you agree to give up your documents, or simply hit you with a $5 wrench until you tell them the password.
You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.
If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.
Finally, if an attacker or malware gets root, FDE isn’t protecting you either.
Even having no pre-boot PIN with SB on is nice, then you only need your user space login where you could even use fingerprint reader if you like. For servers they can already start serving without anyone having to intervene manually (which is nice after power outage, for example).
So yeah, SB, TPM and FDE are a very nice bundle that heavily secures against the most relevant attack vectors.
Yep that’s how my desktops and servers are set up. I only recently started adding the TPM PIN to my laptops for a bit of extra protection from cold boot / evil maid attacks.
Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).
An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there’s no need for key enrolment into firmware, and firmware manufacturers don’t have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer’s key; if you flash something unsigned, a warning pops up Android-style before every boot).
If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.
The main advantage of SB is TPM. At runtime the key isn’t available and unlocking your disk works automatically as long as nothing has been tampered with (which is then also a nice canary: if you suddenly have to enter your password during boot, something’s off).
There’s nothing technically preventing using TPM without secure boot. This is a limitation imposed by OEMs. In fact I have a separate hardware encryption key that I encrypt my (laptop) drive with, and even I don’t (can’t) know the private key. I only know the pin that is needed to unlock it. If motherboard OEMs implemented something like this on the motherboard, with the ability to decrypt the bootloader partition before booting into it, this would solve everything.