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.
I read up on this - it's bricking the system as in "wiping EFI data in ROM", meanin the motherboard is now a brick. Prior to UEFI and systemd, 'rm -rf /' would only wipe the disk, and you could rebuild from backups if you had them
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.
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.
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.
You and a bunch of other people in this thread are continually missing the point, which is certainly not that you could somehow accidentally type rm -rf /. Nobody gives a fuck about that. The point is that you shouldn't be able to brick your hardware from user space, just as the GP has laid out.
There was a time not too long ago when malware could be dealt with by "simply" reinstalling the OS. Now malware can infect your PC's firmware, your USB sticks' and hard drives' firmware, make your graphics card go up in flames, and brick your motherboard.
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...