←back to thread

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

(git.kernel.org)
279 points the_why_of_y | 2 comments | 22 Feb 16 18:08 UTC | HN request time: 0.012s | 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 #
burke ◴[22 Feb 16 19:30 UTC] No.11153561[source]▶
Root is certainly capable, traditionally, of completely hosing all levels of the software stack. Usually it's the OS's job to protect even root from being able to hose hardware/firmware, especially by easy-to-make mistake.
replies(2): >>11153625 #>>11154619 #
kbenson ◴[22 Feb 16 19:40 UTC] No.11153625[source]▶
Yes, which is what we have here. My point is that I don't think there was ever any indication that the systemd developers thought there wasn't a problem to be fixed. That the fix was pushed farther up-stack so it was more comprehensive is not a bad thing in my eyes.

Put another way, systemd mounting efivarfs read-only doesn't necessarily prevent you from bricking your machine by deleting files within that file system, it protects only those using systemd. The problem stems from the nature of efivarfs, and that it was implemented as a file system and not some other interface. Making it default to something more sane is a better (but by no means the best) solution, and that ideally would happen within the source, which is the kernel.

replies(1): >>11153943 #
1. burke ◴[22 Feb 16 20:18 UTC] No.11153943[source]▶
I don't disagree with this, but I still think it's irresponsible of systemd to claim it's a kernel problem but not take steps to help people not brick their systems before it's fixed upstream.
replies(1): >>11154056 #
2. kbenson ◴[22 Feb 16 20:33 UTC] No.11154056[source]▶
What, like his second comment (which was just a few minutes after his first, IIRC), which in it's entirely is '(note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")'? Keep in mind we've had a single month since this bug was submitted. Systemd had a release 11 days ago according to their repo[1], but if that wasn't expected to be picked up and used by distros (which it might not, depending on the distro and what changes have been implemented since the distro shipped/updated systemd), then the appropriate places to fix this are in the kernel and/or as a patch to the distro package for systemd.

Really, I think the two appropriate places for this fix are the kernel, and if that's not expected to be rolled out soon, as a patch to systemd to mount it read-only by the distro shipping systemd. Systemd shipping the fix would only really help the small group of people that install systemd from source during the short window from 11 days ago until the next kernel is available (or that choose to run an older kernel), and makes the whole efivarfs situation a bit more confusing by leaving it read-only and immutable for the future.

1: https://github.com/systemd/systemd/releases/tag/v229