[SOLVED] Confused about Secure Boot device bricking warnings on wiki

Eightie7 · 2026-10-20 00:03:58

This may seem bit nitpicky but I feel like there should be some clearer language on how exactly implementing your own secure boot keys may brick your device, given how serious of an issue that would be. If I'm just bad at comprehension apologies in advance.

Under section 3.1 of the secure boot page on the arch wiki, there is a warning at the top saying that:

Replacing the hardware platform's keys with your own can end up bricking devices on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate or vendor certificates. This is the case in many Lenovo Thinkpad X, P and T series laptops, as well as ASUS TUF Gaming laptops.

The placement of this warning seems to imply that it covers the entirety of section 3.1, but (from my limited understanding, I may be wrong), only section 3.1.4 (Assisted process with systemd) and 3.1.6 (Manual process) as written in the wiki don't involve enrolling Microsoft and vendor keys. Alternatively, section 3.1.5 has instructions that do involve enrolling your keys, Microsoft keys, and the vendor keys, but does have a warning about not enrolling Microsoft and vendor keys:

Some firmware is signed and verified with Microsoft's or your OEM's (for example, Framework laptops) keys when secure boot is enabled. Not validating devices could prevent you from upgrading the firmware, boot other applications (especially Windows), or - in extreme cases - even brick your device. To enroll your keys without enrolling Microsoft's, drop the -m option. To enroll without the keys your OEM has built into your PC's firmware, drop the -f option. Only do this if you know what you are doing.

I understand that this ends with "Only do this if you know what you are doing." but if this is here, why do section 3.1.4 and 3.1.6 not have warnings when they are arguably more applicable to have there? And does this warning cover the same issues as the first warning, or are they similar but different?

And for section 3.1.1 (Determine OpROM signature), is the warning there fixed by applying the instructions in 3.1.5 or is that once again a separate issue?

To avoid soft bricking your device, if you find yourself with a graphics card with signed ROM, make sure your Secure Boot DB retains the necessary issuers after enrolling your own keys.

My point isn't to complain about the Arch Wiki, because I could very well be wrong here, but I'm just trying to find out if I can safely use the instructions in section 3.1.5 to setup secure boot, as my laptop is a Thinkpad X series, which is one of the laptops listed in the first warning, and contains an OpROM signature for my integrated graphics. Sorry for the long speil but I just really don't want to brick my laptop, thanks!

Last edited by Eightie7 (2026-10-20 08:21:14)

-thc · 2026-10-20 06:46:16

Eightie7 wrote:

The placement of this warning seems to imply that it covers the entirety of section 3.1 [...]

Correct.

Eightie7 wrote:

[...] but (from my limited understanding, I may be wrong), only section 3.1.4 (Assisted process with systemd) and 3.1.6 (Manual process) as written in the wiki don't involve enrolling Microsoft and vendor keys. Alternatively, section 3.1.5 has instructions that do involve enrolling your keys, Microsoft keys, and the vendor keys, but does have a warning about not enrolling Microsoft and vendor keys:
Some firmware is signed and verified with Microsoft's or your OEM's (for example, Framework laptops) keys when secure boot is enabled. Not validating devices could prevent you from upgrading the firmware, boot other applications (especially Windows), or - in extreme cases - even brick your device. To enroll your keys without enrolling Microsoft's, drop the -m option. To enroll without the keys your OEM has built into your PC's firmware, drop the -f option. Only do this if you know what you are doing.
I understand that this ends with "Only do this if you know what you are doing." but if this is here, why do section 3.1.4 and 3.1.6 not have warnings when they are arguably more applicable to have there? And does this warning cover the same issues as the first warning, or are they similar but different?

If you read on carefully you stumble across 3.1.8 which explains how to create additional MS "auth" files, which add the standard MS 2011/2023 keys to your own keys. Then you are referred back to enrolling the keys above.

Eightie7 wrote:

And for section 3.1.1 (Determine OpROM signature), is the warning there fixed by applying the instructions in 3.1.5 or is that once again a separate issue?

The sbctl (3.1.5) instructions advise you to keep the option "-f" which enrolls the (default = MS) db and KEK keys from the "Default*" EFIvars key stores adding them to your own - in a sense this is comparable to the section 3.1.8.

Lone_Wolf · 2026-10-20 06:53:40

Moderator Note

Moving to Kernel & Hardware

Eightie7 · 2026-10-20 08:19:58

Thanks for the explanation! I also read some more about sbctl and figured I might try to use the `--append` option on `sbctl enroll-keys` so as to just leave my current keys as they are, and that seemed to work perfectly, as secure boot is active and working, and clearly my device isn't bricked.

Arch Linux

#1 2026-10-20 00:03:58

[SOLVED] Confused about Secure Boot device bricking warnings on wiki

#2 2026-10-20 06:46:16

Re: [SOLVED] Confused about Secure Boot device bricking warnings on wiki

#3 2026-10-20 06:53:40

Re: [SOLVED] Confused about Secure Boot device bricking warnings on wiki

#4 2026-10-20 08:19:58

Re: [SOLVED] Confused about Secure Boot device bricking warnings on wiki

Board footer