Slashdot Mirror
Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)
An anonymous reader writes: For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...
Have you tried not running rm -rf /?
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
Those who do not learn from commit history are doomed to regress it.
While not running systemd is always a good idea, it wouldn't change anything with regards to this, as the EFI variables are in /sys/firmware/efi/vars regardless of what init system you use.
You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.
Incidentally, while systemd was being blamed for this, the underlying /sysfs structures have zippo to do with systemd, so put down the pitchforks.
* Which has never actually been completely true but is a popular catch phrase.
AntiFA: An abbreviation for Anti First Amendment.
No, I wouldn't expect rm -rf to brick my system. I would expect it to remove everything, and then I'd have to reinstall. I would not expect my computer to become unusable to the point that I couldn't reinstall an OS.
They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.
There are two parties to be frustrated with: /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.
-Firmware developers, for not being resiliant in the face of such shenanigans
-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm
XML is like violence. If it doesn't solve the problem, use more.
The kernel dev who wrote the efi code says it's not a systemd problem and following the bug report's suggestion would be the wrong way to solve the problem.
But don't let that stop you from jumping on your favorite whipping boys.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Having come up during the advent of computers, this is PRECISELY why we separated hardware bootstrap firmware from user-accessible code in the first place, and did not make provisions for user-space access to change it. The hardware had to continue to operate and boot regardless of the stupid things users and developers did.
That all went out the window the moment we started with this "update your BIOS from the O/S" bullshit. And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.
No, UEFI doesn't read variables off the disk, there's a kernel module that understands EFI confiig flash space, and exposes the data. Removing files from that pseudo-filesystem is like nuking the config flash area. Note firmware should still be able to tolerate this in theory, but it's not just 'some files got removed'.
The most robust answer is that efivars should not interpret unlink() to erase from flash, instead offering some special ioctl() so a calling program can say they *really* mean it.
XML is like violence. If it doesn't solve the problem, use more.
Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further). Even if EFI vars are broken, that really shouldn't brick your motherboard unless the motherboard itself is buggy. Makes me wonder if the owners have tried resetting their NVRAM, or if that too is perhaps impossible on these motherboards.
No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.
Seems to me that this can be alleviated with selinux. Deny all write access to those paths except when in an explicit context, which the few tools that need that access will have, and even root will have to newrole into to use.
Linux is anything but fragile. Stop blaming the OS for a shitty design in UEFI! Linux is so stable and solid that it lets you run "rm -rf /" and it will actually do what you asked it to until it can no longer figure out the machine it's on and commands needed to talk to a disk. This is a more than 45 year old design. Yes, that's right. In AT&T's original Unix you could also kill a system with "rm -rf /".
'but', 'but', 'but', oh shut up and stop spreading FUD! "rm" is the remove command, "-r" is recursive, and "-f" is force. You need to be root to run this with any success, so it's not like any old user can remove everything.
The problem is that UEFI allows an OS to write to areas which it should not be able to write to. If you open all the PROM in a system it's not just the OS that can brick a system. A malicious person can do so just as easy, and without being so obvious as running "rm -rf /"
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Kinda a mix of everything. It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows. So it's not a Linux (or systemd! Seriously, don't we have enough hate against systemd without TFS adding fuel to the fire?) issue, it's more a design fault.
Clearly UEFI variables are expected to be written to by suitably privileged programs under consumer operating systems, otherwise Windows and Linux wouldn't expose them the way they're exposed. Yet clearly variables are being exposed like this that shouldn't be written to under normal circumstances.
You are not alone. This is not normal. None of this is normal.
This looks like an EFI design bug. Why should EFI allow the OS or any other software brick the system by deleting its variables? Like OO, EFI should allow access to these variables through methods and not directly.
Any changes to the firmware should only be possible by flipping a hardware switch first. Coincidentally, that would also make whole secure boot schmoo obsolete. But we can't have end-consumers control their own computers, can't we?
To be fair, reading TFA it doesn't seem to be a general EFI bug at all, but merely a bug with some implementations of it. TFA mentions "some MSI notebooks", but isn't more specific than that. So yes, this seems like a particular hardware bug, rather than a bug with either UEFI, the Linux kernel, systemd, or any other software bug in general.
BIOS no longer exists at all in modern systems. If you look at its limitations, (which modern OSes had to work around) it's kind of ridiculous that it lasted as long as it did. You have UEFI which is modular (and contrary to popular belief, UEFI has nothing to do with a graphical shell or boot code signing, rather those are optional modules that most motherboard manufacturers include, the first to make their product shiny, and the later because IT Security professionals have been wanting it as a means of eliminating boot code malware; you can load your own keys if you want, and because MS signing keys are so common they're often included by default.)
UEFI remains compatible with things that need BIOS by including a module (often called Compatibility Support Module) that adds archaic crap like certain interrupts if the OS needs them and POST if any hardware you have needs that. Protip: If your setup doesn't need any of that crap, turn off the BIOS compatibility module and you get a faster boot speed.
While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.
XML is like violence. If it doesn't solve the problem, use more.
"To my understanding, you can't boot anymore, at all. If we could simply boot to BIOS and reflash the firmware this wouldn't be such a big issue."
That's entirely too sane. I think you can probably scratch BIOS programming from your list of possible future occupations. You'd have to take a LOT of drugs and stay stoned in order to comply with modern practices
An even better answer would be to try the following concept: A BIOS is a simple and robust, non-writable boot system residing in Read ONLY Memory. BIOSes are small, simple, things that have to be written well since you only get one shot at doing them. Once your device goes into production, you are stuck with whatever the code does.
Note that doesn't preclude insane complexity in the layers of code that are loaded by the BIOS. Modern programming practices can live on .... just not in the lowest level of boot code.
BTW, why do folks think that a design that allows users to inadvertently irretrievably cripple hardware can possibly be secure? If you can accidentally brick the damn thing from a keyboard, what do you think hostile agents can do once they've penetrated your system?
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Having had a less than ideal misttyped rm command go awry on me at one time, I now *always* preface any initial intent to rm anything from the shell with 'echo'. I do this whether or not I am root, look at the output, and if it all looks good, I then repeat the command without 'echo' by hitting the up arrow and deleting the first word.
File under 'M' for 'Manic ranting'
This looks like an EFI design bug. Why should EFI allow the OS or any other software brick the system by deleting its variables? Like OO, EFI should allow access to these variables through methods and not directly.
That you reached +5 makes me weep for Slashdot.
It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it. I can sympathize with the systemd developers on this one (I know, get a rope) because making a unilateral decision to force UEFI read-only over this one issue will have a long-standing and huge impact of system administration (and this goes double controlling large networks of systems).
The fact that root running rm -rf / causes problems shouldn't surprise anyone. Even with newer flags like --no-preserve-root, running as root means exerting ultimate control. Some care is expected or eventually you'll get burned.
Besides, the real question here I think is: Why don't these motherboards have a ROM backup that can be used to restore and boot the boards after catastrophic failure of their saved state? Even without the rm -rf / red herring, that seems like a brain-dead requirement, and one that legacy boards have supported for decades.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
I wished all the config files were located in a single root-level directory (like "home"), perhaps named "cfg".
You've just invented /etc...
Is there anything that prevents code that really needs to write the UEFI from unmounting a default read/only file system and remounting it as read/write? Have the crazies deprecated mount and umount? And really now, how much need to write UEFI is there likely to be in any configuration not designed by complete lunatics?
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
There should ALWAYS be a way to reset a boot loader to a default usable state, whether it's by holding down the power button for 10 seconds or some other hardware based override, or having the bootloader on a microSD card that you can take out and fix on any other computer, or a pre-boot-loader phase where a keyboard override routes to a low level interface where you can fix things, or a jumper or switch inside the case that does the same thing. There should also always be a backup firmware image that can be used.
I'd also think that having the efivar interface expose each variable as a separate file isn't a particularly good idea. Having a simple program to modify variables using another mechanism isn't all that terrible, the convenience of being able to use echo to change a variable isn't worth the risk.
An ARM system I use has u-boot variables at a fixed location on the SD slot boot device, which is hardwired (on the SoC with fuses) to be the only boot source (which can then boot something else either from the SD card or some other device, u-boot itself starts up in well under a second). You can take the microSD card out and put whatever bootloader you want on it, or modify the variable block from the OS by direct writes to a partition (or to a known location on the raw device). The block is checksummed, and u-boot falls back to a default configuration if it's trashed.
The program to read or write variables is quite simple and easy to use in a script.
There's no reason UEFI couldn't do something similar. Last I looked I didn't see an open UEFI implementation on ARM, it might be fun to try replacing u-boot with UEFI and see what it takes to get Linux to boot with it.
The problem is that UEFI missed the KISS principal and is basically an OS itself. In that way, the principals (not necessarily the implementation) of the original PC BIOS are actually a much better target for for an OS bootloader. See uboot (which actually probably goes a little to far the in opposite direction because it lacks the ability to run option rom/support 3rd party plug in devices). You complain about BIOS, but you have to understand that the BIOS design evolved from PCs with 8/16 bit processors and a few KB of ram, all the way to 64-bit computers with hundreds of GB of ram, along the way supported thousands of different peripherals. By comparison UEFI is a tiny slice of the modern computing ecosystem, and most non PC devices abandoned UEFI and instead went for simpler boot mechanisms more reminiscent of BIOS (see cellphones, etc).
BTW; UEFI still does POST (in the generic sense, often with POST codes), its also configures PCIe interrupts and the APIC, which is required for ACPI which remains in UEFI as much as it was in BIOS. Only on ARM64 can you get away from UEFI requiring ACPI to be useful, in the form of UEFI/DT. Which makes one question why run UEFI at all instead of uboot/DT which go together better. (just to be clear ARM64 also "supports" UEFI/ACPI).
Great plan until systemd started putting its "unit" files (great non descriptive name eh? its hard to come up with a less descriptive name) in /lib and then overriding them with /run and /etc.
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.
As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:
And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:
Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.
Hire a Linux system administrator, systems engineer,
Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further)
The problem is UEFI is so complex that many manufacturers make a lousy implementation with a lot of copy-paste code (from Intel's reference implementation). Their QA process seems to be something like, "Does Windows boot? If it does, then it must be ok."
Of course, manufacturers should be blamed for their mistakes, but if UEFI were simpler, there would be less room for mistakes.
"First they came for the slanderers and i said nothing."