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.
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.
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.
This seems irrational:
"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, "
Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?
If Gentoo is ever systemd only I'll be done with Linux.
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.
@whipslash - can we get a fix to the submit button location on the mobile layout so that a double-tap on the spacebar on Android that's 2mm too far to the right doesn't hit ->| (close keyboard) and Submit?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
I'm a little surprised that motherboards don't keep a tiny read-only repository of code to restore from in case you FUBAR the writeable parts. Isn't BIOS code measured in KB? That's trivial space to devote to brick prevention.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
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.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
The very first distro I used was Xubuntu. And like our GP, I wanted to remove some of the unnecessary games that came with the distro, so I too used sudo apt-get remove in order to do so. And I have absolutely no recollection of the entire DE being dependent upon sudoku. So it sounds like the GP is just making shit up. Even if he wasn't, he was still a numbskull, but he probably did make it up.
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.
...systemd isn't in the wrong here....
I did not say it was.
.
The underlying design of having use cases that need write access to UEFI is the issue.
Well it lends itself to accidental nuking if you make a habit of doing operations as root. rm -rf / or any variation of it shouldn't nuke a sstem on it's own. if you don't need sudo before that to do real damage, you're doing it wrong.
"Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
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?
> 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
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
Jesus I thought we'd gotten rid of that stupid "brick" term for simple issues. If it's a COMPUTER - you can't "brick" the damned thing if you take the hard drive out and throw it in a river.
"Bricked" indicates that the firmware is bad. A bad BIOS flash will brick a system. Something of that level. Anything that can be fixed via an OS reinstall ain't "Bricked".
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Never happened to me, but I've come close enough to have managed to develop a healthy "spider sense." Whenever I type "rm" at a hash prompt my adrenaline immediately spikes and I switch to hunt-and-peck-and-verify typing mode.
Someone had to do it.
"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
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
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).
Linux *is* using it wrong, and it's unfixable, because the only "right" way to use it is to use Windows on it, because that's what the consortium intended.
Pretty lousy when a cabal of companies conspire to only support a monopoly in operating systems. You'd think they'd want more competition in that market; it doesn't do hardware makers any good to have all their wagons hitched to a single OS maker that's liable to lead them off a cliff (look at how unpopular Windows is these days).
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.
While that may be true, it could be considered an attack vector.
Major parts of all modern operating systems are dedicated to reducing attack vectors. Even main memory has an OS gatekeeper.
While I sit here wondering why the fucking bios variables dont have an OS gatekeeper, I find it a bit alarming that instead of access restrictions there is in fact a red carpet.
"His name was James Damore."