←back to thread

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

(git.kernel.org)
279 points the_why_of_y | 5 comments | 22 Feb 16 18:08 UTC | HN request time: 0.84s | 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 #
Sanddancer ◴[22 Feb 16 19:51 UTC] No.11153711[source]▶
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.
replies(2): >>11153766 #>>11153807 #
mjg59 ◴[22 Feb 16 20:01 UTC] No.11153807[source]▶
> 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.

replies(2): >>11153966 #>>11153985 #
1. thinkpad20 ◴[22 Feb 16 20:23 UTC] No.11153985[source]▶
> It should be mounted rw because existing userspace expects it to be rw.

Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a firmware partition to be writable. Even if there are any, certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.

replies(2): >>11154041 #>>11154107 #
2. mjg59 ◴[22 Feb 16 20:31 UTC] No.11154041[source]▶
It's not a firmware partition, it's an interface to the nvram variables provided by the firmware. There's a bunch of reasons why these should be writable - you need to be able to modify some of them to do things like reboot into the firmware settings UI, they're used for secure boot key management, you want to be able to choose which OS to boot into on the next reboot or which network interface to PXE off, that kind of thing.

As for why userspace couldn't remount it itself - it could. It doesn't. Changing the behaviour of systemd without changing the behaviour of the rest of userspace would result in userspace being broken, and making that kind of incompatible change is annoying - especially when fixing it in the kernel allows us to avoid that breakage.

3. the_mitsuhiko ◴[22 Feb 16 20:39 UTC] No.11154107[source]▶
> Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a firmware partition to be writable.

Best example of why you need to have it RW: if uefi is in fast boot, the only way to actually enter uefi is to boot an OS and have the OS set the uefi variables so that it goes into the firmware screen on next restart. This is (on Linux) done by changing something in that virtual filesystem.

> certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.

You could probably remount it, but that also means that you all the sudden have concurrency problems with that operation. So not really ideal.

replies(1): >>11154339 #
4. gnud ◴[22 Feb 16 21:12 UTC] No.11154339[source]▶
For this particular example, wouldn't this be best solved with a separate runlevel for "reboot into UEFI"? Stop all daemons, remount all normal filesystems read-only, remount UEFI RW, write variable and reboot.
replies(1): >>11157697 #
5. EmanueleAina ◴[23 Feb 16 09:40 UTC] No.11157697{3}[source]▶
Possibly, but what happens if a faulty script does a `rm` too much in that short time window?

The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.