4 ms·

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads. Currently SB is effectively useless because it will at best

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads. Currently SB is effectively useless because it will at best authenticate your kernel but the initrd and subsequent userspace (including programs that run as root) are unverified and can be replaced by malicious alternatives. Secure Boot as it stands right now in the Linux world is effectively an annoyance that’s only there as a shortcut to get distros to boot on systems that trust Microsoft’s keys but otherwise offer no actual security. It however doesn’t have to be this way, and I welcome efforts to make Linux just as secure as proprietary OSes who actually have full code signature verification all the way down to userspace.

digiown 8mo ago
A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way. Code signature verification is an interesting idea, but I'm not sure how it could be achieved. Have distro maintainers sign the code?
- s_ting765 8mo ago
  Opensuse have been working on making secure boot/TPM FDE unlock easy to use for a while now. https://news.opensuse.org/2025/11/13/tw-grub2-bls/ https://news.opensuse.org/2025/11/13/tw-grub2-bls/
- bboozzoo 8mo ago
  > A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way. Have a look at Ubuntu Core 24 and later. Though it's not exactly a desktop system, but rathe oriented towards embedded/appliances. Recent Ubuntu desktop (from 25.04 IIRC) started getting the same mechanism gradually integrated in each release. Upcoming Ubuntu 26.04 is expected to support TPM backed FDE. Worth a try if you can set up a VM with a software TPM. Keep in mind though, there's been plenty of issues with various EFI firmwares, especially on the appliances side. EFI specs are apparently treated as guidelines rather than actual specification by whoever ends up implementing the firmware.
ahepp 8mo ago
Isn't it possible to force TPM measurements for stuff like the kernel command line or initramfs hash to match in order to decrypt the rootfs? Or make things simpler with UKIs? Most of the firmwares I've used lately seem to allow adding custom secureboot keys.
- direwolf20 8mo ago
  Fine as long as it's managed by the user. A good check is who installed the keys. A user–freedom–respecting secureboot must have user–generated keys.
blibble 8mo ago
you can merge the initrd + kernel into one signed binary pretty easily with systemd-boot add luks root, then it's not that bad
- Nextgrid 8mo ago
  Yes, you can. I really don't want to be in the business of building OSes. If these guys make it so that getting reasonable boot security is a simple toggle, I'd be grateful.
  - NekkoDroid 8mo ago
    On arch it isn't particularly difficult to create UKIs other than changing like 2 lines in `mkinitcpio`'s config. Then there is also `ukify` by systemd which also can create UKIs, which then can be installed with `kernel-install`, but that is a bit more work to set up than for `mkinitcpio`. The main part is the signing, which I usually have `sbctl` handle.
Fischgericht 8mo ago
Yes, "just as secure as proprietary OSes" who due to failed signature verification are no longer able to start notepad.exe. I think you might want to go re-read the last ~6 months of IT news in regards of "secure proprietary OSes".
- charcircuit 8mo ago
  Just because OpenSSL had a CVE posted about today, that didn't mean we should go back to use HTTP for the web.
  - lazide 8mo ago
    It does mean we should recognize that SSL is nice for some basic privacy/security, but not perfect security.
    - charcircuit 8mo ago
      Same with remote attestation. Not all implementations are actually secure. But hopefully over time those security bugs can be ironed out and the cost to extract a key be made infeasable.
      - direwolf20 8mo ago
        Hopefully not. What you have just said is a synonym for "But hopefully over time manufacturers will be able to completely prevent users from running unapproved software."
        charcircuit 8mo ago
        In the case of video game consoles that could be the case. It turned out that being able to run unapproved software results mainly in people playing pirated games. These security measures are reactive to the actions other people have taken. We already experimented with computing being the wild west where there was little to no security. It turned out that bad actors will abuse anything they can find. Even if it's not economical some attackers will still cause abuse. There's always going to be a market for computers that can run unapproved software. I don't see that going away.
okanat 8mo ago
There is some level of misinformation in your post. Both Windows and Linux check driver signatures. Once you boot Linux in UEFI Secure Boot, you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode. You have to sign all of the drivers within the same PKI of your UEFI key.
- Nextgrid 8mo ago
  > you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode You don't need to load a driver; you can just replace a binary that's going to be executed as root as part of system boot. This is something a hypothetical code signature verification would detect and prevent. Failing kernel-level code signature enforcement, the next best step is to have a dm-verity volume as your root partition, with the dm-verity hashes in the initrd within the UKI, and that UKI being signed with secure boot. This would theoretically allow you to recover from even root-level compromise by just rebooting the machine (assuming the secure boot signing keys weren't on said machine itself).
nextaccountic 8mo ago
here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case) sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point) so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots https://wiki.archlinux.org/title/GRUB#Encrypted_/boot https://wiki.archlinux.org/title/GRUB#Encrypted_/boot the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech however, this is still better than, at failure, letting anything run sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level
- ahepp 8mo ago
  Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.
  - Nextgrid 8mo ago
    Secure Boot and TPM are separate things. The current Secure Boot policy gets measured by the TPM but that's about it.
- gorgoiler 8mo ago
  I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this. Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.
Gigachad 8mo ago
Isn’t the idea that the kernel will verify anything beneath it. Secure boot verifies the kernel and then it’s in the hands of the kernel to keep verifying or not.
- Nextgrid 8mo ago
  > the kernel will verify anything beneath it Yes that's the case - my argument is that Linux currently doesn't have anything standardized to do that. Your best bet for now is to use a read-only dm-verity-protected volume as the root partition, encode its hash in the initrd, combine kernel + initrd into a UKI and sign that. I would welcome a standardized approach.
  - jcgl 8mo ago
    Standardizing that approach is one thing that the systemd project has been working on. They've built various components to help with that, including writing specifications (via the UAPI group) on how that should all fit together. ParticleOS[0] gives a look at how this can all fit together, in case you want to see some of it in action. [0] https://github.com/systemd/particleos https://github.com/systemd/particleos
notepad0x90 8mo ago
There is the integrity measurement architecture but it isn't very mature in my opinion. Even secureboot and module signing is a manual setup by users, it isn't supported by default, or by installers. You have to more or less manage your own certs and CA, although I did notice some laptops have debian signing keys in UEFI by default? If only the debian installer setup module signing. But you miss a critical part - Secure Boot, as the name implies is for boot, not OS runtime. Linux I suppose considers the part after initrd load, post-boot perhaps? I think pid-1 hash verification from the kernel is not a huge ask, as part of secure boot, and leave it to the init system to implement or not implement user-space executable/script signature enforcement. I'm sure Mr. Poettering wouldn't mind.
vbezhenar 8mo ago
It is not useless. I'm using UKI, so initrd is built into the kernel binary and signed. I'm not using bootloader, so UEFI checks my kernel signature. My userspace is encrypted and key is stored in TPM, so the whole boot chain is verified.

digiown 8mo ago

A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way. Code signature verification is an interesting idea, but I'm not sure how it could be achieved. Have distro maintainers sign the code?

s_ting765 8mo ago
Opensuse have been working on making secure boot/TPM FDE unlock easy to use for a while now. https://news.opensuse.org/2025/11/13/tw-grub2-bls/ https://news.opensuse.org/2025/11/13/tw-grub2-bls/
bboozzoo 8mo ago
> A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way. Have a look at Ubuntu Core 24 and later. Though it's not exactly a desktop system, but rathe oriented towards embedded/appliances. Recent Ubuntu desktop (from 25.04 IIRC) started getting the same mechanism gradually integrated in each release. Upcoming Ubuntu 26.04 is expected to support TPM backed FDE. Worth a try if you can set up a VM with a software TPM. Keep in mind though, there's been plenty of issues with various EFI firmwares, especially on the appliances side. EFI specs are apparently treated as guidelines rather than actual specification by whoever ends up implementing the firmware.

ahepp 8mo ago

Isn't it possible to force TPM measurements for stuff like the kernel command line or initramfs hash to match in order to decrypt the rootfs? Or make things simpler with UKIs? Most of the firmwares I've used lately seem to allow adding custom secureboot keys.

direwolf20 8mo ago
Fine as long as it's managed by the user. A good check is who installed the keys. A user–freedom–respecting secureboot must have user–generated keys.

blibble 8mo ago

you can merge the initrd + kernel into one signed binary pretty easily with systemd-boot add luks root, then it's not that bad

Nextgrid 8mo ago
Yes, you can. I really don't want to be in the business of building OSes. If these guys make it so that getting reasonable boot security is a simple toggle, I'd be grateful.
- NekkoDroid 8mo ago
  On arch it isn't particularly difficult to create UKIs other than changing like 2 lines in `mkinitcpio`'s config. Then there is also `ukify` by systemd which also can create UKIs, which then can be installed with `kernel-install`, but that is a bit more work to set up than for `mkinitcpio`. The main part is the signing, which I usually have `sbctl` handle.

Fischgericht 8mo ago

Yes, "just as secure as proprietary OSes" who due to failed signature verification are no longer able to start notepad.exe. I think you might want to go re-read the last ~6 months of IT news in regards of "secure proprietary OSes".

charcircuit 8mo ago
Just because OpenSSL had a CVE posted about today, that didn't mean we should go back to use HTTP for the web.
- lazide 8mo ago
  It does mean we should recognize that SSL is nice for some basic privacy/security, but not perfect security.
  - charcircuit 8mo ago
    Same with remote attestation. Not all implementations are actually secure. But hopefully over time those security bugs can be ironed out and the cost to extract a key be made infeasable.
    - direwolf20 8mo ago
      Hopefully not. What you have just said is a synonym for "But hopefully over time manufacturers will be able to completely prevent users from running unapproved software."
      - charcircuit 8mo ago
        In the case of video game consoles that could be the case. It turned out that being able to run unapproved software results mainly in people playing pirated games. These security measures are reactive to the actions other people have taken. We already experimented with computing being the wild west where there was little to no security. It turned out that bad actors will abuse anything they can find. Even if it's not economical some attackers will still cause abuse. There's always going to be a market for computers that can run unapproved software. I don't see that going away.

okanat 8mo ago

There is some level of misinformation in your post. Both Windows and Linux check driver signatures. Once you boot Linux in UEFI Secure Boot, you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode. You have to sign all of the drivers within the same PKI of your UEFI key.

Nextgrid 8mo ago
> you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode You don't need to load a driver; you can just replace a binary that's going to be executed as root as part of system boot. This is something a hypothetical code signature verification would detect and prevent. Failing kernel-level code signature enforcement, the next best step is to have a dm-verity volume as your root partition, with the dm-verity hashes in the initrd within the UKI, and that UKI being signed with secure boot. This would theoretically allow you to recover from even root-level compromise by just rebooting the machine (assuming the secure boot signing keys weren't on said machine itself).

nextaccountic 8mo ago

here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case) sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point) so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots https://wiki.archlinux.org/title/GRUB#Encrypted_/boot https://wiki.archlinux.org/title/GRUB#Encrypted_/boot the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech however, this is still better than, at failure, letting anything run sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level

ahepp 8mo ago
Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.
- Nextgrid 8mo ago
  Secure Boot and TPM are separate things. The current Secure Boot policy gets measured by the TPM but that's about it.
gorgoiler 8mo ago
I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this. Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.

Gigachad 8mo ago

Isn’t the idea that the kernel will verify anything beneath it. Secure boot verifies the kernel and then it’s in the hands of the kernel to keep verifying or not.

Nextgrid 8mo ago
> the kernel will verify anything beneath it Yes that's the case - my argument is that Linux currently doesn't have anything standardized to do that. Your best bet for now is to use a read-only dm-verity-protected volume as the root partition, encode its hash in the initrd, combine kernel + initrd into a UKI and sign that. I would welcome a standardized approach.
- jcgl 8mo ago
  Standardizing that approach is one thing that the systemd project has been working on. They've built various components to help with that, including writing specifications (via the UAPI group) on how that should all fit together. ParticleOS[0] gives a look at how this can all fit together, in case you want to see some of it in action. [0] https://github.com/systemd/particleos https://github.com/systemd/particleos

notepad0x90 8mo ago

There is the integrity measurement architecture but it isn't very mature in my opinion. Even secureboot and module signing is a manual setup by users, it isn't supported by default, or by installers. You have to more or less manage your own certs and CA, although I did notice some laptops have debian signing keys in UEFI by default? If only the debian installer setup module signing. But you miss a critical part - Secure Boot, as the name implies is for boot, not OS runtime. Linux I suppose considers the part after initrd load, post-boot perhaps? I think pid-1 hash verification from the kernel is not a huge ask, as part of secure boot, and leave it to the init system to implement or not implement user-space executable/script signature enforcement. I'm sure Mr. Poettering wouldn't mind.

vbezhenar 8mo ago

It is not useless. I'm using UKI, so initrd is built into the kernel binary and signed. I'm not using bootloader, so UEFI checks my kernel signature. My userspace is encrypted and key is stored in TPM, so the whole boot chain is verified.