Will upcoming firmware updates require Framework secure boot signing keys? The listing here on the LVFS of the not-yet-release 3.06 (I assume, labelled there as 0.0.3.6) says that Framework keys were added to dbx. I have a customised secure boot setup and don’t have any signing keys other than my own, and the dbx is empty. Do I risk system failure if I were to update (once it’s released)?
1 Like
Previous firmware updates have worked fine without requiring any keys from Framework. This is the first time I’ve seen secure boot concepts mentioned in the changelog, so I was assuming a change in how secure boot is handled happened.
I don’t even know where I’d get the public keys from Framework.
If you are not currently experiencing issues loading the Framework-signed UEFI binaries in the FV despite not having their certificates enrolled, you are almost certainly not going to start.
2 Likes
Am I correct in interpreting this statement as there should be issues but magically there are not? Or is that an incorrect interpretation?
There should not be issues. There are currently not issues. It is not likely that issues will arise 
1 Like
Thanks!
Do you know where I can find Framework certificates if I want to enrol them?
Also, do you know if there’s a way to check if some UEFI binaries haven’t been loaded from within Linux or the UEFI interface?
Also, I can report the machine didn’t get bricked 
2 Likes
Excellent!
You can find the Framework certificates in the NVRAM variables dbDefault, KEKDefault and PKDefault. I know[1] that sbctl has support for enrolling the manufacturer’s default certificates when you set up your own key management.
If you want to import them yourself, you’ll need to unpack them with sig-list-to-certs after stripping off the 4-byte NVRAM type header.
If you’re using zsh,
sig-list-to-certs =(dd if=/sys/firmware/efi/efivars/dbDefault-* skip=4B) mfg_cert
It will pop out 1..N files named mfg_cert-X.der
having written that support
↩︎
2 Likes