Secureboot setup mode

Also I was able to re-enroll original DBX backup database while still having platform in setup mode using efi-updatevar:

sudo efi-updatevar -a -e -f <original_dbx>.esl -k <your-KEK>.key dbx

To use KEK key from sbctl:

sudo efi-updatevar -a -e -f <original_dbx>.esl -k /var/lib/sbctl/keys/KEK/KEK.key dbx

My steps for setting up Secureboot with Systemd boot.


But I still have a question:
If I understood section about KEK key on Rod Smith page correctly, is it possible to append/update db or dbx keys later after secureboot setup finished.
However when I try to update dbx when platform isn’t in setup mode, I’m getting an error:

sudo sign-efi-sig-list -g "$(< /var/lib/sbctl/GUID)" -k /var/lib/sbctl/keys/KEK/KEK.key -c /var/lib/sbctl/keys/KEK/KEK.pem dbx /var/lib/sbctl/keys/custom/dbx/original_dbx.esl /var/lib/sbctl/keys/custom/dbx/original_dbx.auth
sudo efi-updatevar -a -f /var/lib/sbctl/keys/custom/dbx/original_dbx.auth dbx
...
Failed to update dbx: Operation not permitted

Same if I try to use KEK key directly:

sudo efi-updatevar -a -e -f /var/lib/sbctl/keys/custom/dbx/original_dbx.esl -k /var/lib/sbctl/keys/KEK/KEK.key dbx
...
Failed to update dbx: Operation not permitted

Am I’m doing something wrong or Framework laptops do not support enrolling db/dbx keys while not in setup mode?

Gentoo (UEFI Stub, ZFS - Native Encryption)
12th Gen i7-1280p

I’m facing the same situation with custom keys and the dbx entry. I recently had to replace my main board due to it frying on a BIOS/Firmware update. These custom keys were created on the original board. They are, a merge of the original factory keys and the custom keys I created, which worked perfectly on the original board with no issues.

Having said that, I don’t recall the BIOS/Firmware version the original board was on when I enrolled the keys but I’m confident it was pre-v3.05 (which is what my replacement BIOS/Firmware shipped with).

Would you kindly post your current firmware version (at the time of the issue) to add additional information? I feel like it might be a firmware regression that is responsible for preventing the dbx record from being updated.

sudo dmidecode -s bios-version

Sure, here’s my system info as of May:

  • Motherboard: Framework Laptop 13 AMD Ryzen 9 HX 370

  • BIOS Version: 3.03 (latest)

  • OS: Arch Linux x86_64

  • Kernel: 6.14.4-arch1-1

I have an Intel Core Ultra Series 1.

I had an issue updating retimer firmware, so I tried various things (this is another topic)… I did reset secure boot with default keys “Restore Secure Boot to factory Settings”, then I did “Erase all Secure Boot Settings” with secure boot disabled. After that, when booting under Linux, none of the UEFI tools were working. See:

So I was unable to enroll my own key using sbctl enroll-keys
To enter into a functional setup mode, I had to follow these steps:

  • In BIOS “Restore Secure Boot to factory Settings”
  • Save and “reboot”, and enter BIOS again (F2 key)
  • In BIOS, clear reset/clear manually all PK, KEK and db certificates and signatures. Do not touch DBX default entries. Do not use “Erase all Secure Boot Settings”
  • Keep secure boot disabled
  • Reboot to Linux, and enroll the keys (including Microsoft keys and Framework firmware keys) with: sbctl enroll-keys -m -f
  • And finally go back to BIOS and enable secure boot
  • Reboot to Linux and check that everything is right: sbctl status

Note: For (at least) BIOS version 3.05 for an Intel® Core™ Ultra Series 1, if somehow the DBX database is changed/updated, for example, by applying UEFI revocation database update, everything will break…

4 Likes

Thanks you so much, this is the only process that worked for me.

Life saver for sure.