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.
Hi, @resample (and everybody else who was so helpful here)!
How did your adventure go? I’m at the same point as you were. Willing to finally secure the machine (which means having only self-created keys for my Linux), but somewhat “scared” as there is also vendor data (Framework’s builtin-db, builtin-KEK, builtin-PK) in addition to the key(s) by Microsoft and I read the same warnings as you - that iGPU blobs may be necessary to be signed for the UEFI to even show. And there are so many DBX entries, I don’t want to get rid of something that’s needed.
I would now go to the UEFI, select “Erase all Secure Boot Settings”, reboot without Secure Boot activated, sign my boot loader, kernel, and initramfs, enroll the keys with “sbctl” and reactivate Secure Boot (hoping for the best ). Is there anything else I need to take care of?
And is there a way to later re-add the Framework and Microsoft-Keys? In case I’ll update the mainboard one day and somebody wants to install some proprietary OS! There’s the “Restore Secure Boot to Factory Settings” option in the UEFI that @kirelagin already mentioned (but didn’t try out). Did anybody verify that this will restore “backups” of the keys?
@kirelagin You showed how you verified that no firmware (drivers for the UEFI) is checked. Could that be something that will later be introduced by some update and then lead to breakage?
sbctl has an option to include any vendor-provided certificates as well as the Microsoft ones! It uses the versions that are provided by the firmware, in the dbDefault (and KEKdefault) variables.
You won’t need the signature dbs for the Microsoft key if you are not enrolling the Microsoft key. I have to admit that I’m not sure how to add Microsoft dbx separately, although I’m pretty sure it shows as part of Framework firmware in fwupd, so it should be possible to get them from there somehow.
Haven’t tried myself, but I think people here on the forum reported that resetting secure boot settings to defaults restores the Microsoft stuff.
That depends on the hardware, so I don’t think it would be possible.
You should include the entire DBX, rather than redacting any part of it. If you do ever reinstall the Microsoft keys it will suddenly become meaningful again.
It’s a list of binary and certificate hashes to never allow on your machine. Unless you have a very good reason to be running one of those binaries (which is going to be either malware or a vulnerable bootloader,) you’ll want to block them all.
Just as a FYI for future readers: I took a leap of faith and deleted all signatures/keys (okay, just one in DBX… But PK, KEK and DB were empty.) which made “Secure Boot” unavailable on the next reboot in the UEFI. Using “Restore Secure Boot to Factory Settings” worked as expected all all Signatures/keys were restored as they were before.
Now, I can start playing around with Secure Boot eventually
I can confirm that secure boot enrollment was a breeze and seems to work without microsoft keys. I didn’t do anything like firmware update since then but everything normal works fine. This on Arch linux using sbctl. The only thing that I had to deal with was that I made a type when setting up my partition type for the /boot partition and had to fix the type in gdisk but it was an issue of my making.
). Is there anything else I need to take care of?