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 shouldn't be mounted rw, and only exposed at root. It shouldn't be mounted by default. It shouldn't even be a bloody filesystem. EFI variables have so much metadata and other information attached to them that trying to wedge them into the filesystem is just asking for problems like this. Were the maintainers smart, they'd dump the file system all together, because it's a nonsensical way of presenting this data.

> It shouldn't be mounted rw

It should be mounted rw because existing userspace expects it to be rw.

> It shouldn't be mounted by default.

It should be mounted by default because it's information that's relevant to various pieces of userspace.

> It shouldn't even be a bloody filesystem.

With hindsight, it should absolutely not have been a filesystem. There's very little metadata associated with EFI variables and the convenience of exposing this in a way that can be handled using read and write is huge, but real-world firmware turns out to be fragile enough that this was a mistake. But, in the absence of a time machine, there's very little I can do to fix that now.