←back to thread

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

(git.kernel.org)
279 points the_why_of_y | 4 comments | 22 Feb 16 18:08 UTC | HN request time: 0s | source
Show context
nkurz ◴[22 Feb 16 19:19 UTC] No.11153467[source]▶
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

replies(3): >>11153507 #>>11153589 #>>11153676 #
kbenson ◴[22 Feb 16 19:23 UTC] No.11153507[source]▶
> 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

replies(6): >>11153532 #>>11153561 #>>11153670 #>>11153711 #>>11153722 #>>11154994 #
pyre ◴[22 Feb 16 19:53 UTC] No.11153722[source]▶
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.

replies(3): >>11153841 #>>11153983 #>>11154137 #
kbenson ◴[22 Feb 16 20:23 UTC] No.11153983[source]▶
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.

replies(1): >>11154159 #
1. Nitramp ◴[22 Feb 16 20:45 UTC] No.11154159[source]▶
> 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.

replies(1): >>11154202 #
2. kbenson ◴[22 Feb 16 20:52 UTC] No.11154202[source]▶
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.
replies(1): >>11155312 #
3. pyre ◴[22 Feb 16 23:47 UTC] No.11155312[source]▶
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.

replies(1): >>11155560 #
4. kbenson ◴[23 Feb 16 00:42 UTC] No.11155560{3}[source]▶
I understand and agree with all of this, I'm just not sure how it follows from what I wrote. The problem has a fix scheduled (what this submission is about), and in a fairly short period of time (~30 days for a fairly esoteric[1] bug).

To my mind there are two places to fix this, in the kernel for a real mitigation technique that helps "solve" the problem, and in the distros for quick fixes and hacks, or backports of the kernel fix, as necessary. Systemd pushing a fix of their own 1) only affects distros using systemd, while this problem affects all recent distros that use efivarfs), 2) probably won't get picked up by distros immediately excapt as a backported fix anyway, as I doubt most of them push new versions of something as integral as systemd every time a new version is out, at least not with a lot of testing, and 3) would not have been a good fix, and would have required the utilities that still needed access to actually remount a filesystem.

1: Triggering this problem is not as easy as what you (and I) wrote in most instances, as / has special consideration in rm, and generally requires the "--no-preserve-root" flag.