Hacker News Reader

Comment by Nextgrid | Hacker News Reader

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.

View on HN

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

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

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.

Secure Boot and TPM are separate things. The current Secure Boot policy gets measured by the TPM but that's about it.

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.

Encryption is just a baseline. Nobody should have unencrypted personal computers.

You can have both full disk encryption AND a tamper protection!

Sorry, I wasn’t clear enough. We’re talking about three things here:

(1) Encryption: fast and fantastic, and a must-have for at-rest data protection.

It is vulnerable to password theft though. An attacker might insert evil code between power-on and disk-password-entry. With a locked down BIOS / UEFI, the only way to insert the code is to take the boot drive out of the device, modify it, put it back, and hope no one notices. “Noticing” in this case is done by either:

(2) Trust chaining: verify the signatures of the entire boot process to detect evil code.

(3) Tamper detection: verify the physical integrity of the device.

My point is that (1) is a given, and out of (2) or (3), I’d rather have the latter than deal with the shoddiness of the former

> 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

Reminds me of my old Chromebook Pixel I wiped chromeos from. Every time it booted I had to press Ctrl-L (iirc) to continue the boot, any other keypress would reenable secure boot and the only way I knew to recover from that was to reinstall chromeos, which would wipe my linux partition and my files with it. Needless to say, that computer taught me good backup discipline...

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".

Just because OpenSSL had a CVE posted about today, that didn't mean we should go back to use HTTP for the web.

It does mean we should recognize that SSL is nice for some basic privacy/security, but not perfect security.

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.

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."

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.

Huh? Why should people who pay for the hardware not be able to run whatever they want? Why include them as ‘attackers’?

Shareholders über alles?

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.

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.

you can merge the initrd + kernel into one signed binary pretty easily with systemd-boot

add luks root, then it's not that bad

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.

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.

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.

> 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.

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

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?

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/

> 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.

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.

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.

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.

> 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).

Reply on news.ycombinator.com