Never Update Your UEFI “BIOS”, Especially With LVFS on Linux. Also, systemd-boot is a Plot to Overthrow the PC’s Owner.
Reprinted with permission from Ryan Farmer.
Why You Should Never Update Your UEFI “BIOS”, Especially With LVFS on Linux.
Also, systemd-boot is a Plot to Overthrow the PC’s Owner.
systemd’s entire purpose is to replace the Linux kernel’s features with something that systemd does itself, incompetently. It’s full of bugs.
One of their latest antics is systemd-oomd, which is going over well (sarcasm) and you can read all about what Fedora users have to say about it on Reddit. I refuse to even think about installing THAT on my PC.
I know to shut down memory hogs before opening a memory hog and I use ZRam so it’s usually not a big issue.
I’ll deal with this before there’s an out-of-memory and a program written by Facebook and IBM is going around randomly murdering, up to and including my entire desktop session, kicking me to a login screen, ruining EVERYTHING.
It’s difficult to even imagine that I was horrified when their first “proposal” was just to handle “mount” or when one of their next ones was to handle DNS.
systemd’s secondary purpose is to kill GNU’s bootloader, GRUB, and replace it with one that can lock down the whole computer per Microsoft’s orders.
To quote Debian on “Secure” Boot:
code must not be subject to GPLv3, “or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device.
Code that is subject to such a license that has already been signed might have that signature revoked.
For example, GRUB 2 is licensed under GPLv3 and won’t be signed.“
-One of Microsoft’s requirements for signing a bootloader.
systemd-boot is not designed to be better than GRUB 2, but to make it possible to just directly “sign” it with Microsoft and refuse to give the user the right to run an alternative version of systemd-boot which doesn’t lock their computer down and remove a significant amount of access to it.
Shim+GRUB 2 already does this, but the user can just turn off Security Theater Boot in the UEFI setup, and then remove shim and update grub.
mokutil only exists to deal with shim, so you can get rid of that too at the same time.
Debian “supports” Security Theater Boot now, so I’ve removed support for it so I couldn’t even turn it back on like this at the firmware level if I wanted to.
I blogged at least three times about why “UEFI is Trash”.
See; System76 Ditches UEFI Firmware Trash, Ships Coreboot Firmware on Linux Laptops, UEFI is Trash: Part 2 “Destroy the Computer to Continue Using Windows 11!”, and More Work on Debian 12. UEFI is Trash Part 3: Fixing a Lenovo Restart “bug”.
It is not even plausible that UEFI, like it is, could enforce Security Theater Boot, because it’s got thousands of CVEs (security holes) and unless people flash their firmware every month most of them will all work.
Lenovo has updated this PC over 30 times.
Many times you flash it, it will do something to ruin Windows Boot Manager or Bitlocker, if you use Windows.
Each month they “fix” 6-12 CVEs.
So you tell me how well this was designed.
Also, nobody wants to brick their computer, especially if it’s not under warranty, so they don’t even install the UEFI updates. Like I don’t.
If you flash it and it goes so wrong it kills the hardware, you’ll be paying for this mess yourself. (A new computer.)
When I had Windows 10 on this machine, I followed Lenovo’s instructions, to the letter. Windows was ruined twice. Wow. UEFI is terrific.
TPMs, which is how Windows Bitlocker “encrypts” (it’s backdoored for the government) your storage, are just too twitchy to ever use for anything serious. You will lose all of the data you haven’t backed up at some point, if you provoke it enough times.
Updating the UEFI isn’t supposed to change the state of the TPM, but when has anyone at Intel, Microsoft, and the BIOS industry ever followed their own documentation?
So when it DOES change the state of the TPM and the TPM refuses to unlock your Bitlocker drive, then “Microsoft Fastboot” (which turns off the keyboard until you get to Windows, only you can’t get to Windows now) prevents you from typing in the recovery key.
You DID write down the recovery key? No, well, that’s fine.
At this point, you couldn’t type it in even if you wanted to.
So to deal with firmware updates, under Windows, you need to (1) backup your data, (2) make sure the computer is under warranty in case the flash destroys it (5% chance each flash), (3) write down the Bitlocker recovery key (or just go to your Microsoft account because they have it in case the police ask for it), (4) disable Fast Boot in the UEFI setup for when the TPM gets pissed about the Flash, and (5) learn how to use Recovery Mode to re-install Windows Boot Manager, or possibly all of Windows.
Very simple, and elegant!
Otherwise, have fun while the CVEs pile up in the UEFI. Security Theater Boot will be REAL real enforceable now!
Since there is a 5% chance of wrecking the UEFI’s flash memory each time you use a flasher, then if you installed every update Lenovo released for the Thinkbook, you’d have destroyed the laptop almost twice in the last 3 years, statistically.
Since this is the situation under Windows, I have no confidence in fwupd/LVFS and uninstalled it from Debian.
I’d recommend everyone just uninstall fwupd/LVFS, or at least disable the repo on every machine before you give that machine Internet access, even if your OEM puts anything meaningful there.
(Lenovo doesn’t, so it’s just Microsoft dbx blacklists for Security Theater Boot.)
OEMs BARELY test their computers under Windows, which is what’s up with those “Unsupported Processor” BSoDs lately.
These are PCs that were “designed for Windows”, and they are as horrible as that sounds.
So, why on Earth would a Linux user be flashing the thing (UEFI) the PC can’t work without using something written by IBM Red Hat, using systemd?
At least without systemd poking around and flashing firmware in shoddy ways, all IBM Red Hat’s software can really do is screw up your operating system.
That is, at least, recoverable by re-installing the OS, worst case. █