Is there a reason why the secure boot thing could not have had several secure boot slots and each one independent of others? So that microsoft world could run securely and other people could boot their system securely out of another slot?
Just wondering what the technical reason would be that Microsoft had to control the whole of the PC??
Surely, the control of the boot environment and any the the boot shims could have been restricted to system that could boot out of said shim. Then the two worlds could have securely co-existed could they not ?
It irks me that Microsoft managed to shim their way into the Linux boot process like this. No key signed by Microsoft should ever come into play when booting Linux, on a moral basis.
Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer. If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own har…
TIL UEFI is apparently a "Windows boot process" /s
Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.
The day infosec nerds get rid of their unhealthy obsession with expiration and realize that systems irrecoverably breaking on an arbitrary random instant or requiring a true source of time to work are REALLY FUCKING INCOMPATIBLE with the real world, they might actually get something done. Until then, please don't bother the rest of us trying to get work done (and having to cleanup the mess you made - what do you mean you can't just update it?!)
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configurat…
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 as normal devices controlled by OS drivers without the ACPI/UEFI layer.
A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
You're conflating secure boot with measured/verified boot.
They don't work in tandem? I enable secureboot with sbctl(securebootctl) and enroll keys in a TPM using the same tool as far as I can remember. Or is this just some technical detail that in practice is under the same tools and settings?
In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.
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?
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.
There's some link between secure boot and encryption. If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase. Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by t…
for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone t…
Unless you're using a SED, your EFI system partition is unencrypted. It would be trivial to build a malicious copy of popular open source UEFI bootloaders (grub, refind, zfsbootmenu, etc), and a bootable USB stick that scans your EFI system partition, replacing your unencrypted bootloader with a malicious one. This attack could then be applied by relatively unskilled people in a couple minutes ("boot this flash drive, wait until the screen says "done", power it off"). I hope your laptop is never out of your possession for more than a couple of minutes! (For example, the TSA at the airport, geek squad or other repair centers, or classically an evil maid).
I didn't realize that the Secure Boot certificates that allow us to boot Linux at Microsoft's pleasure are things that expire. So all Microsoft has to do to kill end-user Linux is... nothing.
How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
No, the real mistake was putting the root of trust anywhere else than the user.
From Microsoft's point of view, that's not a mistake. It's the whole point! The user is a potential pirate, after all.