←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 2 comments | 18 Jul 25 03:53 UTC | HN request time: 0.421s | source
Show context
palata ◴[18 Jul 25 09:28 UTC] No.44602753[source]▶
[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?

replies(3): >>44602785 #>>44602973 #>>44603027 #
vbezhenar ◴[18 Jul 25 10:05 UTC] No.44602973[source]▶
Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.

Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.

replies(1): >>44603007 #
1. palata ◴[18 Jul 25 10:10 UTC] No.44603007[source]▶
> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys

Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?

Would the solution be that the GPU should load the firmware from the OS?

replies(1): >>44615940 #
2. okanat ◴[19 Jul 25 14:52 UTC] No.44615940[source]▶
You don't need to be able to build them. Just sign them or sign the keys that sign the third party blobs/binaries.

Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.

What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.

Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.

With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.