Ubuntu 17.10 corrupting BIOS of many Lenovo laptop models

Userspace utilities expect it to be mounted r/w, so changing it unilaterally to read-only will break things if it is intended as a "bug fix" -- which is annoying to ship to users if one fix causes another regression. For example, OpenRC ships it as r/o, but various tools like grub-install do not remount on their own, so they fail strangely. It could be fixed to have userspace mount it, but those things require coordination. Remounting is also a race-y condition for various tools to engage in on their own, for obvious reasons. It also does not change the fact those EFI variables are still exposed as writable once mounted r/w, so even closing the race condition, your system can still be bricked due to a bug.

The fix for this in the kernel was to block writes to non-standard UEFI options in efivarfs making them immutable, which prevents accidentally nuking them. This was the actual source of the 'bricking' in the original bug. This is a low-cost fix inside the kernel, which already has to deal with hostile hardware in a million other ways and sanitize various other things to stop all kinds of hardware from crapping itself, just like this. It is also relatively easy for distributions to backport, does not require changing mount semantics for systemd, does not break existing UEFI userspace tools (which would take time to coordinate, and will not manipulate non-standard variables anyway), and stops people from bricking themselves.

Logistically, the kernel is really the best and most low-cost place to fix such an issue for everyone, regardless of mount policies on efivarfs in the init system -- in a way that is actually safe for everyone. It would have taken the same time, or more time, to fix it badly (e.g. break userspace tools and require userspace remounts) as fixing it this way. You could level better complaints at UEFI or efivarfs or systemd in general than this one, all things considered...

> (I'm not the one who knows best, on this topic)

I like how people somehow breathlessly say "systemd developers prove they don't know shit, of course its their fault!!!" and then immediately follow it up with a bunch of fairly basic questions and just admit "oh by the way i don't know what i'm talking about, can anyone tell me otherwise???"

systemd annoys me sometimes and I don't like some of its design decisions, but by far its worst "feature" is it causes people who are very unsure of what they are talking about to suddenly become experts about it.

At the very least, efibootmgr. The problem with userland mounting it itself is that it has no code to mount it itself because even before systemd everybody mounted the filesystem read/write.

> Why would you even write to efi ? Maybe at boot, i don't know, but certainly not while running ?

A whole bunch of reasons. Maybe you want something that's tied to the hardware without relying on the OS (eg, tpmtotp). Maybe you want to be able to differentiate between a clean and unclean system shutdown. Maybe you want to indicate that the system should install a firmware update next time it's in boot services.

> In my opinion systemd is at fault, as they aim to be the "system" and yet every once in a while prove that they don't know shit.

At the time this issue was raised, nobody knew shit. We had no idea that removing certain variables might prevent a machine from booting. If we had done, I'd have written the filesystem differently.

> I'm not the one who knows best, on this topic

I wrote the code in question. I am one of the people who does know best on this topic. Systemd did nothing wrong.

The BIOS is not to be messed with by user software or the OS. It should be signed and only changed by the manufacturer tool to update it.