3 ms·

There are quite a few instances[1] where adding your own signing keys bricks the device. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Inter

There are quite a few instances[1] where adding your own signing keys bricks the device. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

growse 4y ago
Huh, wasn't aware of that. Reading through, it looks like this is just talking about Microsoft "Secured-core" hardware, which seems to be hardware specifically marketed to provide a Microsoft-certified boot chain. I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).
- Foxboron 4y ago
  It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate". UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't. This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick. This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn. There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.
vladvasiliu 4y ago
As others have said, it's not a full-on brick (though I can see how it can be a pain to fix). However, the third-party MS certificate can be signed with your own keys, as described on that same page [1]. I don't have a need for that (my PCs don't need any option ROMs), but I did sign MS's main Windows key so that I can dual boot Win11 / Arch (which MS doesn't sign) with my own key registered in the UEFI. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Dual_booting_with_other_operating_systems https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

growse 4y ago

Huh, wasn't aware of that. Reading through, it looks like this is just talking about Microsoft "Secured-core" hardware, which seems to be hardware specifically marketed to provide a Microsoft-certified boot chain. I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).

Foxboron 4y ago
It's a bit more complicated. The UEFI drivers and Linux distributions are signed by the same certificate, the "Microsoft 3rd party UEFI Certificate". UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't. This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick. This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn. There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.

vladvasiliu 4y ago

As others have said, it's not a full-on brick (though I can see how it can be a pain to fix). However, the third-party MS certificate can be signed with your own keys, as described on that same page [1]. I don't have a need for that (my PCs don't need any option ROMs), but I did sign MS's main Windows key so that I can dual boot Win11 / Arch (which MS doesn't sign) with my own key registered in the UEFI. [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Dual_booting_with_other_operating_systems https://wiki.archlinux.org/title/Unified_Extensible_Firmware...