Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

251–260 of 272 posts

Re: Linux and Secure Boot certificate expiration

#251

Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.

I would rate the experience as 6.5/10 If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike. Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work und…

Mok has a big problem where malware can get you to sign malicious code with it. Having the signing keys be accessible to the end user is dangerous.

Re: Linux and Secure Boot certificate expiration

#252
post #146

Earlier quoted context omitted.

No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.

> SB starts with actually firmware already booting something. I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature? EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment i…

> on a laptop the first bootloader can be installed by the user and nothing checks its signature?

It should be signed by the manufacturer, so you shouldn't be able to. Loaded by a shim even smaller in the CPU, part of Boot Guard and Platform Secure Boot, if I'm not remembering wrong.

> say on Linux, if Secure Boot verifies up to my /boot partition (does it?)

No. It verifies one signed file, usually Grub EFI shim. Which then should check everything you want. Unlike Windows, desktop Linux distros rarely have the best SB system. Poettering has described this issue in depth.

Re: Linux and Secure Boot certificate expiration

#253

Earlier quoted context omitted.

> Every couple of years MS do an update that messes up multi-boot/dual boot IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.

The idea that MS should be able make orders that distros then have to follow is insane. If MS breaks something it absolutely is their fault.

No it's not. Microsoft has to disable outdated and vulnerable signed bootloaders to stop them being used for secure boot bypasses. Microsoft worked with RH to get things updated which they did, it's just distros for caught slacking and were shipping an outdated vulnerable boot loader.

I know it's the norm to bash Microsoft and they do a lot of crappy things, but in this case it was just certain distros not taking security updates seriously, which is why a lot never broke (such as Fedora)

Re: Linux and Secure Boot certificate expiration

#254

Earlier quoted context omitted.

> Every couple of years MS do an update that messes up multi-boot/dual boot IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.

So Windows installs something that brakes Linux boot. How are you supposed to boot Linux to install a fix? Am I expected to reboot into a different OS twice a day and check for updates? Am I slacking for not doing so?!

No, Windows updated a UEFI component that disables outdated and vulnerable bootloaders to stop them being used as secure boot bypasses.

Re: Linux and Secure Boot certificate expiration

#255

Earlier quoted context omitted.

Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).

There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though. 1. You can sign and verify initramfs, it's supported by bootloaders. 2. You can merge kernel and initramfs into UKI and sign the whole image. I don't know why that's not implemented.

For UKI I imagine a big hurdle is the size of the images (given /boot/efi is usually only big enough for bootloaders, not kernels and initram) and custom kernel modules (e.g. Nvidia).

There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.

I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.

Re: Linux and Secure Boot certificate expiration

#256
post #237

Earlier quoted context omitted.

Consider using Heads with TPM and Librem Key to detect possible compromise of your boot stage. It doesn't obey MS but you.

that's still secure boot, isn't it? just not uefi but homegrown? fine with me. I read GP as rejecting the whole idea. to point at another elephant in the room: at some point I came to realize that the ME is a x468 running some BSD. that little bitch has full access to your machine. if trust and security is the objective, we're in for a hard ride to find trustworthy hardware.

ME is disabled and neutralized on my Librem 15: https://puri.sm/learn/intel-me/

Re: Linux and Secure Boot certificate expiration

#257

Earlier quoted context omitted.

The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.

All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI. The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better…

> Linux lets you build a devicetree as part of the kernel.

And it's absolutely awful as an end user if you have anything even slightly unusual.

Re: Linux and Secure Boot certificate expiration

#258

Earlier quoted context omitted.

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck. The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut. Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time. What's happening in sm…

> It's the "security" of their 30% App Store cut.

> most PC manufacturers don't have their own app store.

I feel like you misunderstand what Secure Boot does. It has absolutely nothing to do with userspace apps or app sideloading. It's true that you can't easily sideload apps on Apple devices - but that has absolutely nothing to do with Secure Boot, neither do userspace apps have anything to do with it on any other device.

Re: Linux and Secure Boot certificate expiration

#259

Earlier quoted context omitted.

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> Is SSL also an evil technology designed to take away freedom from the internet? If it were not for Let's Encrypt, YES! Secure boot would not be a problem if it were trivial to enroll keys. Give me a big message like: "The OS you are trying to run is signed by an unknown key sha256:whateverthefuck IF YOU ARE NOT RUNNING AN INSTALLER YOU ARE MOST LIKELY CURRENTLY BEING ATTACKED AND SHOULD NOT PROCEED. If you are runn…

At least half the reason I have a Gemini server running (the protocol, not the LLM), but no web sever anymore, is that it uses Trust On First Use, like SSH, rather than requiring all the complexities of CAs.

Not saying all of the web should switch to that while keeping everything else the same, but in some contexts it is just nice to use something simpler, as long as the risks are known to users.

Re: Linux and Secure Boot certificate expiration

#260
post #44

Earlier quoted context omitted.

mind to elaborate? I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. the promise of secure boot and trusted computing is backdoor-free boot. what is in your eyes evil and garbage about that?

> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.

> you have to trust the firmware anyway

If it's FLOSS wirh reproducible builds, your trust can be minimized, since the community verification is going on constantly. Also, your suggestion is quite inconvenient and cumbersome to use and set up.

Post reply on HN