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

You're missing the end of that quote:

> But beyond that: root can do anything really.

... so running "rm -rf /" as root should brick your motherboard because it's the responsibility of the motherboard manufacturer to protect against this. That's all fine and dandy in an idealized world, but in the "real world" there are going to be motherboard manufacturers that play fast and loose with these things.

The kernel should mount it read-only. If root wishes to delete or modify the contents, root can remount it read-write.

The kernel isn't in charge of mount options, that's the job of userspace (generally an init system). In any case, you would end up needing a way to mount it RW to accommodate legit uses of the non-broken EFI vars, at which point you're back where you started. This fix addresses it by having the kernel identify and protect only broken (or at least, non-standard) EFI vars.

> In any case, you would end up needing a way to mount it RW to accommodate legit uses of the non-broken EFI vars, at which point you're back where you started.

Not necessarily. Leaving it "wide open" for anything to accidentally write to it all of the time vs. just mounting it readwrite when you actually need to write to it are two different risk profiles.