wsx

Sorry, I forgot about ACPI :)

Now that you posted this, I think I recall one friend telling me that hibernation killed his laptop. But this was over 10 years ago and I only know about one such incident.

OTOH, what UEFI gave us is basically a portable and convenient API to brick any machine from any OS.

Well, it's still a solution to problem which shouldn't exist in the first place. Before UEFI, x86 boxes were hard to brick unless you really knew what you were doing.

Well, the insanity would rarely enter official releases.

There is no comparison between the bugginess of BIOSes and OpenSSH.

> These hardware vendors at all levels - storage controllers, chipsets, radios, and more all have absolutely no QA on their code

Hardware vendors do have QA, but it's mainly about ensuring that things work, not about trying to break them in every possible way. Safety and security seems to be notoriously hard for people who have been taught how to make things work, but not how to make them fail.

> I just know the next laptop I buy will be whatever the highest end liberated Chromebook at the time is, preferably without cancerous firmware blobs that control everything, but that seems unlikely considering how anti-freedom Intel is.

Yep, I don't think you'll find x86 Chromebooks without blobs. Nowadays the only way Intel provides to boot their hardware is "here, take this binary and put it at the beginning of your BIOS".

Same thing with AMD, btw.

I'm not sure how moving boot settings from one OS-accessible place to another improves security.

If you are bothered by people booting unauthorized disks on your hardware, enforce signature checking on OS images.

The thing I find particularly hard to grok is that they came up with this idea of putting disk-specific boot information on the motherboard. Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.

Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.

Probably not in this case, because affected systems don't give even a slightest sign of life.

It's very funny until they drop BIOS compatibility mode from new machines.

tl;dr: This can permanently brick some/many/all? UEFI devices. Three cases confirmed so far on Lenovo/MSI/unknown hardware.

Linux distribution other than Arch are likely to be affected as well because systemd is hardcoded to mount the EFI variables pseudo-filesystem with RW access on every boot.