←back to thread

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

(git.kernel.org)
279 points the_why_of_y | 1 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 #
mozumder ◴[22 Feb 16 20:05 UTC] No.11153841[source]▶
It's firmware. It's supposed to brick your system if you ruin it. Firmware is basically hardware. It's not a multi-user protected-mode operating system.

It's the responsibility of the OS to make sure it doesn't ruin firmware.

replies(2): >>11153912 #>>11153918 #
LordKano ◴[22 Feb 16 20:15 UTC] No.11153918[source]▶
It shouldn't be possible to brick hardware by running 'rm'.
replies(1): >>11154293 #
mozumder ◴[22 Feb 16 21:06 UTC] No.11154293[source]▶
Right, but it should be possible to brick hardware through firmware updates.

Again, this is the OS's fault.

replies(2): >>11154819 #>>11155281 #
1. pyre ◴[22 Feb 16 23:41 UTC] No.11155281[source]▶
The EFI variables are just that. Variables not an entire firmware. I think this is where you confusion is. What is happening here is that these variables are presented to the user as a filesystem under /sys. If you run 'rm -rf /' (or even 'rm -rf /sys'), you will start "deleting" these variables (which I assume either sets them to a null-equivalent value, or somehow removes them entirely from wherever they are stored). It sounds like:

  rm /sys/efivar/MyVariable
is roughly equivalent to:

  var obj = {MyVariable: 1};
  obj.MyVariable = null;
or:

  var obj = {MyVariable: 1};
  delete obj.MyVariable;
This bricks the firmware, because some of these variables end up being required. It's on the firmware maker / motherboard manufacturer to make sure that there is a way to recover from this rather than having the firmware fail to startup because some variables are missing.

My understanding is that firmware made to spec would not brick over the the EFI variables getting wiped. The motherboards that are encountering these issues are running firmware that is cutting corners. Unfortunately cutting corners and ignore specs is nothing new for hardware manufacturers who are more concerned with the manufacture of the physical devices and usually put only the minimum amount of effort into getting any sort of software components (firmware, OS device drivers, etc) running.