“Just” is doing a lot of heavy lifting in that solution.

https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

Note sbctl is one of the easier tools to do this.

So, believing this is very, very hard.

If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.

Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.

Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.

Personally, I do both secure boot and encryption.

Or is this just some technical detail that in practice is under the same tools and settings?

If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc...

Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.

Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.

It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.

Sounds like a cleaner solution than any of the ones in the article too!

It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.

https://wiki.archlinux.org/title/Chrony#Real-Time_Clock

Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.

If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"

As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".

With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.

If the resulting key works indefinitely, the expiration date on my signing key is utterly meaningless.

Microsoft's Authenticode has been doing this for a long time, allowing a signature to be considered as valid long after the signing certificate expired.

https://learn.microsoft.com/en-us/windows/win32/seccrypto/ti...

A different model would be to only allow a given EFI binary to be booted if it was installed before the deadline, but that might well have a different set of complications.

If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.

Just wondering what the technical reason would be that Microsoft had to control the whole of the PC??

Surely, the control of the boot environment and any the the boot shims could have been restricted to system that could boot out of said shim. Then the two worlds could have securely co-existed could they not ?