[SOLVED] Secure Boot and custom keys on the AMD motherboard

Can someone confirm whether replacing the platform keys with your own is supported on the AMD motherboard?

And if the answer to that is yes, is it safe to clear the factory Secure Boot certificate keyset, and then re-enable Secure Boot without installing the Microsoft Corporation UEFI CA 2011 certificate and bricking the motherboard? According to FAQ · Foxboron/sbctl Wiki · GitHub, only computers without an iGPU are generally affected; though, I’d like to be on the safer side, which is why I’m asking.


I haven’t tried so there’s no answer, but I think these are helpful to you.



Hopefully these help :slight_smile:

1 Like


Now, is someone brave enough to attempt to erase the factory keys to verify whether the motherboard POSTs and is fully-functional without them? :grin:

I did this a little bit ago successfully, and yes - selecting “Erase all Secure Boot Settings” puts it in Setup mode so you can enroll your keys.

I hadn’t played around with it a ton before (these were the same options provided for 11th gen Intel), but I don’t think there’s any risk of bricking your device unless you absolutely cannot boot with secure boot disabled. You can always go back into the bios to reset things, and I’m pretty sure the restore option reinstates the factory keys.

1 Like

Unfortunately, according to the page on Secure Boot in ArchWiki, there is still a risk of soft-bricking the device if the Option ROM of one of its components is signed against Microsoft’s keys. Furthermore, if I understand the process of setting Secure Boot up correctly, you can only find out if it soft-bricks for you after enrolling exclusively your keys and then enabling Secure Boot.

So, unless resetting UEFI settings by cutting power supply to the motherboard restores its factory keyset, in the worst case scenario, you won’t be able to make it POST again, mandating a replacement.

1 Like

Oh, that’s something I forgot to mention in my post. I did not include the Microsoft keys via sbctl when I enrolled my keys. Unless the OpROMs are signed differently for the same hardware platform for some reason, anecdotally it works fine for me.

1 Like

@kjhoerr To be sure, did I understand correctly that you enrolled your keys (without Microsoft’s ones) to the UEFI, on an AMD-based Framework laptop?

Yes. To be sure, I reran the process for enrolling my sb keys since that’s easy enough to do:



@kjhoerr I’m going to attempt to enroll my own keys any day now but before I do, I need to be 100% sure I won’t soft-brick my motherboard, because I need the computer to remain in a working state in the coming weeks.

So, I want to ask you, have you encountered any problems that might’ve been connected to Secure Boot after updating to the now-latest stable firmware (3.0.3)? And if you haven’t, may you please confirm that the only keys that are listed under the DB, KEK, and PK options in the Secure Boot section of the firmware settings are the ones that belong to you?

I know I’m beginning to display symptoms of a broken record but all I need is some more reassurance :sweat_smile:

1 Like

Nope, been running on 3.03 since that was released without any issues.

Right, I’m not sure how it looks by default, but there’s only one entry each for PK, KEK, and DB, and the owner GUID for each of those is the same as is stated in sbctl status. The DBR, DBT, DBX have no entries.


Just wanted to also confirm that I enrolled my own keys and no vendor keys, and everything works fine!

# sbctl status
Installed:		✓ sbctl is installed
Owner GUID:		40b8c598-846b-421e-95d0-78ec53efa8e8
Setup Mode:		✓ Disabled
Secure Boot:	✓ Enabled
Vendor Keys:	none

There are no OpRoms whose signatures would be checked during boot on Frameowrk 13 AMD.

# tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep BOOT_SERVICES_DRIVER || echo 'Nothing!'
1 Like