Was also discussed on lobsters a few days ago.
I do think this article adds something. The analysis of Matthew Garret is useful, because it will hopefully end the blame-game of the anti-systemd camp.
(You can have any opinion about systemd, but this problem is caused by (in order): bad EFI firmware, allowing unlink on efivarfs, exposing EFI variables as a filesystem. Though I think that Garret takes too much blame, it’s mostly bad EFI firmware.)
It’s easy to poke from the sidelines, so can someone explain why it’s like this? I read the GitHub page and it seemed, to me, like the systemd authors were very dismissive of something that could happen by an accident. The argument seemed to be that systemd modifies the directory sometimes when it does something, but couldn’t that be remounted as rw in those cases or am I missing something?
[Comment removed by author]
what would happen if the motherboard came fresh out of the box with a flat lithium battery?
They’re stored in NVRAM, not a battery-backed store. A bad flash from the factory could result in a DOA motherboard, but this is true if it only contains firmware, too.
Linux kernel mounts this particular filesystem read/write instead of using extended ACLs (people get irrationally upset if you try to constrain what root can do)
The Linux kernel is a complete bystander here. SystemD mounts EFI as a read-write (for no well-articulated reason) filesystem (for no well-articulated reason).
systemd is absolutely not at fault here, in my humble opinion; we can achieve this result just by an rm -rf /
SystemD is the only relevant party at fault. (I’ll accept that the firmware makers deserve some share of the blame, but they’re out of the picture here. You’re never going to be able to get them to fix or even own up to their mistakes. And this is a tiny drop in the vast ocean of appallingly bad firmware we’ve had foisted on us.) They put critical rarely-updated values in easy reach of commonly-used and easily-misused userspace tools. Buggy and fragile hardware is a fact of life; if you’re not willing to work around it, you’re not qualified to write software to run on it. If that offends Lennart’s sensibilities, he should find another line of work.
SystemD mounts EFI as a read-write (for no well-articulated reason) filesystem (for no well-articulated reason).
systemd does is because userspace tools require it to work. efivar(1) is the prime example. They are used to add linux boot-managers into the UEFI launch list, as the most common example.
Buggy and fragile hardware is a fact of life; if you’re not willing to work around it, you’re not qualified to write software to run on it.
Wasn’t kernel the part that was supposed to abstract over and hide hardware quirks? Also, why would anyone would be allowed to tell anyone else what they are allowed or qualified to do?
If that offends Lennart’s sensibilities, he should find another line of work.
This is plain old personal attack and flamebait. AFAIK Mr. Poettering was not ‘offended’ by bad firmware, but bunch of trolls that raided the GH bug report.
Isn’t that a fairly rare event that is explicitly kicked off by some process? Seems odd to keep a sensitive component vulnerable to an accident all the time when the operation needed is transient.
That’s correct. But no one knew that efivars could be used to brick faulty, non-conformant hardware until… Thursday?
The hubbub seems to not be about that it was discovered Thursday, but that the response is “WONTFIX”.
Best case scenario: the BIOS is well designed and removing everything “merely” resets it to factory settings. That’s still not what I want an errant rm to do.
I don’t see why that should have surprised anyone. It didn’t surprise me (edit: that deleting the EFI config could brick the motherboard), though it certainly surprised me that it was exposed as a read-write filesystem. And
faulty, non-conformant hardware
We generally just call this “hardware”.
SystemD does is because userspace tools require it to work.
Userspace tools don’t require it to be a filesystem, they don’t require it to be mounted when they’re not running, and they don’t require it to be read-write when they’re not actively writing to it. It actually needs to be writable for at most a few seconds out of the entire lifetime of the device.
Wasn’t kernel the part that was supposed to abstract over and hide hardware quirks?
How is the kernel supposed to know what is and is not a valid EFI configuration? It’s entirely possible to achieve the same end result with valid-looking configuration changes, you just can’t trivially do it by accident.
In fact, there are a lot of ways to brick your hardware that the kernel can’t reasonably protect against. You could write bogus firmware to all sorts of places, including the motherboard, attached drives, indeed, most random peripheral hardware. It’s the responsibility of the tools that actually do this to protect against bricking hardware. rm has no business being a tool that can write firmware, which is why you’ll note that your wifi card’s firmware isn’t exposed as a filesystem.
This is plain old personal attack
Of course it is. I’m personally attacking him. His response to this bug is incompetent and idiotic. Charitably, I’m assuming his response is because he thinks EFI firmware should protect against this (it should) and is writing software for the world he wants to live in rather than the world he does (which is completely unrealistic, and for which this would be the wrong behavior anyway) hence “offending his sensibilities”, but if you’d prefer, I could just assume he’s stupid.
Is your goal to just be an asshole or is there something else you’re hoping to achieve?
If it’s the former, please stop. If it’s the latter, I suspect there may be better more constructive choices available to you.
Does anyone really use rm -rf /?
rm -rf /
Nah, these days I use sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
I point this out every time this comes up, that option is for GNU rm ONLY. POSIX rm doesn’t use it, busybox doesn’t use it, etc.
Getting to be a bit of a tangent, but Solaris/Illumos also won’t let you delete /, which they believe is a valid reading of POSIX. Although that of course won’t keep you from removing /*
Aside from “I’m not using this system anymore, let’s see what happens when I delete everything”, it’s relatively easy to fat-finger. Remember this pretty great bug? It’s easy to imagine similar typos resulting in recursive removal of /sys, e.g. “rm foo/bar /*”.
rm foo/bar /*
Or this classic: https://github.com/valvesoftware/steam-for-linux/issues/3671
Thanks for reminding me it’s time to do another backup :)
That was a terrible bug. I think some automatic jailing/sandboxing would be great for these sort of stuff ups and general security, “Steam is trying to access Pictures/ allow it?” wait, why? Denied. “Facebook is trying to access your contacts…”
It’d be great if it weren’t so difficult to decouple things like this from the Linux kernel space; I really wish there’d be two truly defined layers there where the userspace system could focus on solving problems like this.