Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

151–160 of 272 posts

Re: Linux and Secure Boot certificate expiration

#151

Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.

UKI + secure boot works really well, but it is somewhat manual of a set up on Arch (what isnt). If properly set up the only files you generate are: - /efi/loader/random-seed - /efi/EFI/Linux/arch-linux.efi - /efi/EFI/Linux/arch-linux-fallback.efi and the .efi are all automatically signed by hooks. You can even skip a bootloader and boot the images directly.

I just finished setting this up and it's definitely this easy. The hardest part was growing the ESP to dual boot with Windows but that is basically just copy/paste the files to a bigger partition and change the partition type GUIDs.

Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complicates it. I just created a 20-year db key pair with openssl (and PK and KEK just to make sbctl happy due to a bug), then installed the public db cert into the UEFI manually via the ESP. Didn't even need to use setup mode, although I suspended BitLocker on the Windows partition to let it reseal its key with the new PCR 7 measurement after the db update.

To finish securing it I have a separate key for PK and KEK and have already installed Microsoft's 2023 UEFI certs in the db (and added the 2011 cert to dbx with the updated bootmgr).

Re: Linux and Secure Boot certificate expiration

#152
post #31

Earlier quoted context omitted.

You'd have control over what boots on your computer then...

you literally have though. you can self sign everything and set up uefi to only boot your signature

Only on x86 secure boot implementations. On most devices with trusted boot, you don't have this option.

Re: Linux and Secure Boot certificate expiration

#153

Earlier quoted context omitted.

UKI + secure boot works really well, but it is somewhat manual of a set up on Arch (what isnt). If properly set up the only files you generate are: - /efi/loader/random-seed - /efi/EFI/Linux/arch-linux.efi - /efi/EFI/Linux/arch-linux-fallback.efi and the .efi are all automatically signed by hooks. You can even skip a bootloader and boot the images directly.

I just finished setting this up and it's definitely this easy. The hardest part was growing the ESP to dual boot with Windows but that is basically just copy/paste the files to a bigger partition and change the partition type GUIDs. Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complic…

I just used sbctl to generate and install a platform key in setup mode. It worked well.

Re: Linux and Secure Boot certificate expiration

#154

Earlier quoted context omitted.

Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck. The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut. Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time. What's happening in sm…

Freedom vs safety should be contextual. I’m not free if I don’t have choices and secure boot is a choice. Having it improves both my freedom and security somewhat. I want both unlocked and locked hardware, for different purposes.

Secure Boot is almost never a choice. It's just something a hardware vendor hits you with, whether you like it or not.

Re: Linux and Secure Boot certificate expiration

#155

Earlier quoted context omitted.

you literally have though. you can self sign everything and set up uefi to only boot your signature

Only on x86 secure boot implementations. On most devices with trusted boot, you don't have this option.

uefi on non x86 is a non starter for most people anyways. not that uboot is better

Re: Linux and Secure Boot certificate expiration

#157
So in 2025,2026 the simplicity of BIOS still haunts us. I realize this time it is a one-off cert issue, but there have been so many other non-trivial paper cuts in secure boot and UEFI implementation that I can't help but see this upcoming fix as spinning a roulette wheel of fixed/failed/bricked.

Re: Linux and Secure Boot certificate expiration

#159

Earlier quoted context omitted.

Firmware needs maintenance because unless you're doing stuff for the aerospace industry, you're not mathematically proving that your firmware is bug-free. Eventually someone will need to install updates. Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.

Not to mention that firmware updates are often necessary for things like supporting new CPUs. Immutable firmware means that your system can never improve or expand to support new hardware, and I would hate to have to buy a new motherboard to support a new CPU.

You shouldn't need new improved proprietary software to support new hardware, that's just wrong. They're just bundling free apps into hardware at that point.

"New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.

Re: Linux and Secure Boot certificate expiration

#160

Earlier quoted context omitted.

Freedom vs safety should be contextual. I’m not free if I don’t have choices and secure boot is a choice. Having it improves both my freedom and security somewhat. I want both unlocked and locked hardware, for different purposes.

Secure Boot is almost never a choice. It's just something a hardware vendor hits you with, whether you like it or not.

It’s a choice I make all the time. I disabled it on one of my computers just last night. I’ll probably turn it back on today. It’s easy to toggle.
Post reply on HN