Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

For context, this is in reference to a bug that was discussed a couple weeks ago: https://news.ycombinator.com/item?id=10999335

  Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' 

Essentially, systemd defaulted to a configuration where the computer's motherboard could be permanently destroyed by removing a 'file' from the command line. The bug reporter argued that this was unduly dangerous, but the systemd developers thought that systemd was working as intended.

Here's a reasonably impartial discussion on a FreeBSD list that gives an overview: https://forums.freebsd.org/threads/54951/

And from that thread, here's a link to Matthew Garrett (the creator of efivarfs) saying that efivarfs is at fault here rather than systemd: https://twitter.com/mjg59/status/693494314941288448

> but the developer's thought that it was working as intended

Really? Is that evidenced by Lennart's response to this, which stated "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root."[1]? I think it implies the opposite.

1: https://github.com/systemd/systemd/issues/2402

It happens rarely, but actually I totally agree with Lennart on this one. Maybe not for the very same ultimate reasons, but nevertheless, I agree.

Being able to brick hardware through a very oftenly used action (unliking a filesystem entry) throws us back into the times where one could damage display devices beyone repair by feeding them scan frequencies outside their operational range or by destroying hard disks by smashing the heads into a parking position outside of the mechanical range. We left those days behind us some 20 years ago: Devices got smart enough to detect potentially dangerous inputs and execute failsafe behaviour. It's just reasonable to expect this from system firmware.

When talking about (U)EFI variables we're not talking about firmware updates, which are kind of a special action (and even for firmware updates its unacceptible that a corrupted update bricks a system¹). Manipulating (U)EFI variables is considered a perfectly normal day-to-day operation and the OS should not have to care about sanity checks and validity at boot time. (U)EFI is the owner and interpreter of these variables, so it is absolutely reasonable to expect the firmware to have safeguards and failsafe values in place.

IMHO (U)EFI is a big mess, a bloated mishap of system boostrap loader. And I'm totally against trying to workaround all the br0kenness in higher levels. The more and often systems brick due to the very fundamentals of (U)EFI being so misguided, the sooner we'll move on to something that's not verengineered.

----

¹: Just to make the point: When we developed the bootstrap loader for our swept laser product we implemented several safeguards to make it unbrickable. It's perfectly fine to cut the power or reset the device in the middle of a firmware upgrade. It safely recovers from that. Heck, the firmware in flash memory could become damaged by cosmic radiation, the bootloader would detect it and reinstall it from a backup copy in secondary storage.

> I totally agree with Lennart on this one.

There's a certain rich irony that Lennart is being flogged for following the Unix tradition (root can do anything, including blow up their monitor with bad X configs); that his detractors are suggesting userland tools manage their hardware (normally the job of the kernel in a Unix system); that systemd ought to be expanded to manage hardware (after years of complaining it's too big), presumably by adding whitelisting capabilities and a database of known-good/known-bad UEFI implementations.

I guess at least it demonstrates how utterly unhinged some people become when his name is attached to anything.