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

Framework Laptop 13
1

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.

2 Likes
2

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

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot

https://wiki.gentoo.org/wiki/Secure_Boot

3

Hopefully these help :slight_smile:

IMG_1694
IMG_16943024Ă—4032 1.79 MB

IMG_1695
IMG_16953024Ă—4032 1.71 MB

2 Likes
4

Cheers!

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:

5

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.

2 Likes
6

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
7

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
8

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

9

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

image

image
image2256Ă—1504 418 KB

5 Likes
10

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

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.

2 Likes
12

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!'
Nothing!
1 Like
13

Hi, @resample (and everybody else who was so helpful here)!

How did your adventure go? :slight_smile: 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 :wink: ). 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?

Thanks a bunch!

14

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.

1 Like
15

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.

16

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.

17

Thanks for your replies!

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 :slight_smile:

18

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.

screenshot_2024-02-10_15-00-00_656822877

19

I’m still stumped on this. I keep getting dropped into grub rescue. On that note, is anyone who’s successfully achieved secure boot with Arch also using luks encryption, btrfs, snapper, and grub? I’m trying to narrow down what may be throwing me. Thanks.