3 ms·

While the commands and procedures on this page still work fine (the screenshots are a welcome addition!), I find the Arch Linux wiki to be a bit more up to date

While the commands and procedures on this page still work fine (the screenshots are a welcome addition!), I find the Arch Linux wiki to be a bit more up to date: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... The Arch wiki also adds some additional warnings that you may want to check into. For instance, my Thinkpad with an Nvidia GPU will be bricked if I use the normal API to load secure boot keys, because on boot certain firmware is executed before the setup utility, which means that if that firmware fails verification, the entire laptop becomes unbootable. The workaround (load keys through the UEFI setup utility instead of any other tools) doesn't let me get rid of the manufacturer keys and take full control, unfortunately. I'll keep Lenovo's choices here in mind next time I buy a laptop. Thanks to updates to sbctl, you can create keys with `sbctl create-keys` rather than typing out complex openssl commands. sbctl's `enroll-keys` should also make the key enrollment procedure easier. Your distro probably also comes with an optional package manager hook so you don't need to repeat the sign commands every time your bootloader updates.

Foxboron 1y ago
>Thanks to updates to sbctl, you can create keys with `sbctl create-keys` rather than typing out complex openssl commands. sbctl's `enroll-keys` should also make the key enrollment procedure easier. I mean, reading Rod Smiths post is what originally made me write secure boot tooling many years ago. I didn't understand why it had to be soooo complicated. If you read the original `efi-roller` project I started out with you'll see it's largely just a wrapper around the stuff in Rod Smiths book, that was later refined by actually implementing a proper library in Go and tooling on top. https://github.com/Foxboron/efi-roller https://github.com/Foxboron/efi-roller
- jeroenhd 1y ago
  It was definitely the most comprehensive article on actually using secure boot at the time it was written, that's for sure. I just don't want people to think that now, a decade later, you still need to mess with shell scripts calling openssl commands to get secure boot to work.
tiberious726 1y ago
If you use the -m flag with enroll-keys, won't that also load the MS keys, which the Nvidia firmware should be signed by, allowing verification to pass?
- jeroenhd 1y ago
  Probably. There's also a Lenovo key in there, I believe, which sbctl probably doesn't know about. My laptop is out of warranty and I'm not interested in starting a legal battle should the firmware bug persist and soft brick the motherboard, so I'm not going to try it.

Foxboron 1y ago

>Thanks to updates to sbctl, you can create keys with `sbctl create-keys` rather than typing out complex openssl commands. sbctl's `enroll-keys` should also make the key enrollment procedure easier. I mean, reading Rod Smiths post is what originally made me write secure boot tooling many years ago. I didn't understand why it had to be soooo complicated. If you read the original `efi-roller` project I started out with you'll see it's largely just a wrapper around the stuff in Rod Smiths book, that was later refined by actually implementing a proper library in Go and tooling on top. https://github.com/Foxboron/efi-roller https://github.com/Foxboron/efi-roller

jeroenhd 1y ago
It was definitely the most comprehensive article on actually using secure boot at the time it was written, that's for sure. I just don't want people to think that now, a decade later, you still need to mess with shell scripts calling openssl commands to get secure boot to work.

tiberious726 1y ago

If you use the -m flag with enroll-keys, won't that also load the MS keys, which the Nvidia firmware should be signed by, allowing verification to pass?

jeroenhd 1y ago
Probably. There's also a Lenovo key in there, I believe, which sbctl probably doesn't know about. My laptop is out of warranty and I'm not interested in starting a legal battle should the firmware bug persist and soft brick the motherboard, so I'm not going to try it.