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.
tiberious726 · 4h 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?
Foxboron · 12h 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.
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.
edoceo · 12h ago
Does anyone use UEFI to directly load Linux ? Currently I use Syslinux but I've heard it can be directly booted and remove Syslinux from the process. And it still works with initrd and my appended command line options. This page is in my pinned reference for it - but I'm nervous to try lest I brick my machine.
Anyone here made it work? If UEFI can do it, what is the bootloader for?
Foxboron · 12h ago
The Linux `vmlinuz` binary is an EFI executable that implements a minimal stub loader to load rest of the kernel and initrd.
You can use `efibootmgr` to insert the `vmlinuz` binary as a boot entry. But honestly, you are better off using a proper bootloader as it makes things a lot simpler for you to manage.
The UEFI bootloader menu is mediocre if you are lucky, terrible in most cases.
Cu3PO42 · 12h ago
Yes, you can boot Unified Kernel Images (UKI) directly from UEFI without an additional bootloader. A bootloader may still be helpful to manage your various entries and provide you with a menu to select one of many entries to boot.
mixmastamyk · 8h ago
Yes, I tried this on a tablet and it works. However I found systemd-boot friendlier to use at boot time, because you don’t have to go into firmware to pick an entry (kernel). And can edit config on disk.
But on a typical boot it works just fine either way.
jeroenhd · 11h ago
As others said, you can do it. It's very useful for some scenarios.
Bootloaders and boot managers take away a lot of the management, which is welcome with many UEFI screens. You have some, like HP's, that will let you browse to an EFI file and/or manually manage custom entries, basically removing the need for a bootloader in most cases, and then there are the ones like my MSI board that will corrupt their own configuration if you call efibootmgr too many times and that hide any custom boot defintions from the management UI so you have to use the Linux command line to set the preference right.
Whether you need one is up to you to decide. Most distros default to using a bootloader because that's what users expect, but there's no strict requirement for using bootloaders if you don't want Grub or rEFInd or systemd-boot on your system. However, if you want to do things like "edit the kernel parameters once every now and then", a bootloader is probably the way to go for most people.
When you're building an embedded Linux application that will only boot kernels signed by your company, I don't see the need for a bootloader, though.
phoronixrly · 13h ago
The guide is great and I've followed it to success several times. It fails whenever the odd vendor decides it should really offer a slightly buggy implementation.
For example one that will allow you to enter sb setup mode, clear EFI keys, but not offer a way to enroll new ones from the firmware setup UI. While simultaneously making the EFI KeyTool fail enrollment with a cryptic error message. :)
sylware · 15h ago
"You better have those software rid of security flaws properly signed!"
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.
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
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.
Anyone here made it work? If UEFI can do it, what is the bootloader for?
You can use `efibootmgr` to insert the `vmlinuz` binary as a boot entry. But honestly, you are better off using a proper bootloader as it makes things a lot simpler for you to manage.
The UEFI bootloader menu is mediocre if you are lucky, terrible in most cases.
But on a typical boot it works just fine either way.
Bootloaders and boot managers take away a lot of the management, which is welcome with many UEFI screens. You have some, like HP's, that will let you browse to an EFI file and/or manually manage custom entries, basically removing the need for a bootloader in most cases, and then there are the ones like my MSI board that will corrupt their own configuration if you call efibootmgr too many times and that hide any custom boot defintions from the management UI so you have to use the Linux command line to set the preference right.
Whether you need one is up to you to decide. Most distros default to using a bootloader because that's what users expect, but there's no strict requirement for using bootloaders if you don't want Grub or rEFInd or systemd-boot on your system. However, if you want to do things like "edit the kernel parameters once every now and then", a bootloader is probably the way to go for most people.
When you're building an embedded Linux application that will only boot kernels signed by your company, I don't see the need for a bootloader, though.
For example one that will allow you to enter sb setup mode, clear EFI keys, but not offer a way to enroll new ones from the firmware setup UI. While simultaneously making the EFI KeyTool fail enrollment with a cryptic error message. :)
...