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.

No, you are missing the context of the earlier paragraph, which says "Well, there are tools that actually want to write it." so it needs to be accessible in some way. Making it truly read-only is not really feasible, and goes against the Unix philosophy of "root can do anything." That's not to say that we shouldn't make it harder for root to do some things, such as brick your system. In the end, the fix still doesn't prevent root from bricking a system in the case the firmware is badly coded, it just makes it a bit harder. Mounting read-only by default or defaulting all files to immutable until changed by chattr are not hard hurdles to overcome for root, but they the do make it harder than it would be without them, which in this case is a good thing.

> ... so running "rm -rf /" as root should brick your motherboard because it's the responsibility of the motherboard manufacturer to protect against this.

You are assuming "only writable by root" means "root can write without any restrictions" which is a fairly uncharitable reading, and requires assumptions about his intent which are not evident.

I could make a statement such as "cars in the united states can only be legally driven by people of an appropriate age" and you could assume I meant that's all that needs to apply and start calling out my statement as wrong, or you could assume I was aware of the additional requirement of a driver's license, or you could ask me to clarify my point of view. I just don't believe the first option is conducive to useful discussion, nor do I think it's appropriate to use assumed information in a negative way towards a third party.

Edit: s/disparage/use assumed information in a negative way/ for lack of better phrasing coming to mind. The statement wasn't really disparaging, just an uncharitable interpretation, so I don't want to overstate that.

> goes against the Unix philosophy of "root can do anything."

I don't think that's a useful perspective here. This is not a feature - nothing should ever want to permanently brick a motherboard, there's no use case for that. There's no benefit to allowing root to do this. The OS is supposed to abstract the hardware in a way that it can be safely operated.

I think you are mistaken about some of the details here. We are talking about root being able to write to efivarfs, which is needed for some valid reasons. Unfortunately, there are firmware implementations out there that don't handle some variables being overridden/wiped, and it bricks the system. So, the problem is bad firmware, exacerbated by the choice to represent EFI variable as a filesystem and what happens when you do a "rm -rf /" (in the simplest example). So, in my eyes, root should be able to write to efivarfs when needed, but we should mitigate this problem in some way so it's hard to accidentally brick your system by making it a little harder (but not impossible) for root to write to this filesystem. It's not possible to allow root to write to EFI while still ensuring that it can't brick the machine, because the responsibility for that capability lies with the firmware developers.

My understanding is that the amount of software that wants/needs to write to efivarfs is fairly small[1] compared to the amount of software that is normally run with root privileges.

The fact is that 'rm -rf /' is a common mistake, both at the command line (i.e. manually typing) and in scripts that don't adequately protect against things like missing variables. E.g.:

  MY_DIR=
  rm -rf "$MY_DIR/"

The fact that this could brick a system is a big deal. Pushing blame around doesn't do anybody any good.

[1] I realize that boot loaders like grub are everywhere and probably need to write to efivarfs, but that's still a data point of 1. Would it be that difficult for grub and it's related scripts to upgrade to remount the filesystem readwrite when it needs to perform an operation? I'm sure it's only been a couple of years since efivarfs functionality was even added to grub.