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.
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…
It’s worth noting that, at least for me, updating to the latest secureboot firmware undoes secureboot (on ArchLinux) and the steps to re-enable it as delineated above remove the update. In other words, at least for now, it seems like I can either have secureboot or the latest secureboot firmware update, but not both.
Ditto. Fortunately I never had the problem issue of erasing the DBX/etc signatures, thanks to those who reported it here, but before setting up Secure Boot on my FW-12, 13th Gen (running NixOS, via Lanzaboote), I had already updated my firmware per:
Unfortnately, that decision landed me in more or less the same situation as other folks here. Sure enough, though, by going back into BIOS, enabling “Restore Secure Boot to Factory Settings” then going through the process again as @benjarobin reports above, I was able to get secure boot set up, if only at the cost of rolling back my firmware.
Hopefully some kind of fix will be forthcoming, if not already available?
Are you saying, that after the BIOS updates, if you follow my procedure, secure boot is not restored? You have to roll back the BIOS firmware and follow my procedure?
Thx for the response, @benjarobin! To clarify, when I followed your full procedure, including the “Rollback..” step, secure boot did work. The first time I tried, however, I did everything except the rollback step, because I never deleted the factory DBX, PKX and KEKX signatures, only the PK, KEK and DB sigs. Perhaps I misinterpreted, but I believed deleting those sigs was the only reason to do a roll back. So that first time, while I still had the full firmware upgrades in place, secure boot did not work after following the all the other steps, including the --microsoft / -m and --firmware-builtin / -f flags.
So now, similar to what @Ken_Chappell was saying above, I believed I could only have secure boot working at the cost of having to rollback firmware updates. … or so I thought?
Actually, looking at it now, I don’t believe it rolled back everything. Before I did the firmware update, I had version 0.0.3.4 (how it came from the factory) and flashed 0.0.3.7 via Framework Laptop 12 Intel® Core™ 13th Gen BIOS 3.07 Release STABLE. Running fwupdmgr get-devices shows me that the System Firmware is still at 0.0.3.7 and Internal SPI Controller (BIOS) is v 3.07.
So I guess enabling “Restore Secure Boot to Factory Settings” only effected the relevant parts of the UEFI settings it needed to and left the rest in place?
“Restore Secure Boot to Factory Settings” only resets the UEFI variables to their default values. It doesn’t do any rollback. The BIOS firmware is unaffected.
