Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

51–60 of 272 posts

Re: Linux and Secure Boot certificate expiration

#51

Post by chabad360 »

It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser.

The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.

SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.

Re: Linux and Secure Boot certificate expiration

#52

Post by jeroenhd »

mkj wrote: post #12

It's not just Linux - certificates to sign Windows are also affected in 2026. https://support.microsoft.com/en-us/topic/windows-secure-boo... https://techcommunity.microsoft.com/blog/windows-itpro-blog/... Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop b…

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.

In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.

In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

Re: Linux and Secure Boot certificate expiration

#54

Post by TacticalCoder »

> Any installed distribution should have a bootloader signed with its own key that will continue to boot

I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).

So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).

Am I correct in my understanding that this only affects my installation media and not my already installed systems?

Lastest Debian stable FWIW.

Oh well, I take it it's going to be mokutil and whatnots when I get back home.

Re: Linux and Secure Boot certificate expiration

#55

Post by palata »

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already]

I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:

1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).

2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).

Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.

How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?

Re: Linux and Secure Boot certificate expiration

#56

Post by jeroenhd »

pdimitar wrote: post #46
blkhawk wrote: post #19

Earlier quoted context omitted.

Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. S…

What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?

Evil maid and rootkits, mostly. It's also part of the trust chain that unlocks an encrypted disk without having to enter a password.

On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).

Re: Linux and Secure Boot certificate expiration

#57

Post by CoolCold »

saidinesh5 wrote: post #4

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.

just doublechecked with "Confirm-SecureBootUEFI" - says True on my laptop which used > 1 year. I'm pretty sure on the previous system which was used for 4 years it was on too - have not noticed any issues.

Windows 10 and then 11

Re: Linux and Secure Boot certificate expiration

#58

Post by deknos »

sugarpimpdorsey wrote: post #16
greatgib wrote: post #3

It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.

It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.

orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing.

and secure boot is still the antichrist, but we have to live with them.

Re: Linux and Secure Boot certificate expiration

#59

Post by jeroenhd »

saidinesh5 wrote: post #4

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.

It works pretty well out of the box unless you're trying to combine Linux with Nvidia hardware. Even with Nvidia hardware it doesn't take that much effort to make it work, but as usual, Nvidia requires taking extra steps.

What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.

Re: Linux and Secure Boot certificate expiration

#60

Post by jeroenhd »

palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.

AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.

Post reply on HN