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 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.
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.
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.
@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
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.
