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.
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.
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.
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.
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.
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'
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."