Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Bug Security IT Linux

Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com) 699

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.
This discussion has been archived. No new comments can be posted.

Running "rm -rf /" Is Now Bricking Linux Systems

Comments Filter:
  • LOL, what? (Score:4, Interesting)

    by gstoddart ( 321705 ) on Monday February 01, 2016 @10:01AM (#51413419) Homepage

    So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?

    Because this sounds so horribly broken it isn't funny.

    Actually, no, it's actually quite funny in a big giant "WTF" kind of way.

    • Re:LOL, what? (Score:5, Insightful)

      by Dolda2000 ( 759023 ) <fredrik@dolda2[ ].com ['000' in gap]> on Monday February 01, 2016 @10:22AM (#51413583) Homepage
      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.
      • Re:LOL, what? (Score:5, Informative)

        by tricorn ( 199664 ) <sep@shout.net> on Monday February 01, 2016 @12:47PM (#51414873) Journal

        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.

      • Re:LOL, what? (Score:5, Interesting)

        by phantomfive ( 622387 ) on Monday February 01, 2016 @02:19PM (#51415617) Journal

        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 [intel.com]). 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.

    • Re:LOL, what? (Score:5, Interesting)

      by squiggleslash ( 241428 ) on Monday February 01, 2016 @10:39AM (#51413737) Homepage Journal

      Kinda a mix of everything. It's worth noting that, according to ex-kernel hacker Matthew Garrett [twitter.com], 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.

      • Re:LOL, what? (Score:4, Insightful)

        by Anonymous Coward on Monday February 01, 2016 @10:59AM (#51413951)

        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?

      • It's worth noting that, according to ex-kernel hacker Matthew Garrett [twitter.com], you can achieve the same bricking using a 20 line program in Windows.

        You mean to say that if I accidentally type that 20 line program on Windows, compile it, type the name and hit Enter, my box is toast? That's scary!

        Thanks for the warning. I'll be wary of those 20 lines. What were they again, just so that I do not type them accidentally?

  • Huh? (Score:4, Funny)

    by Anonymous Coward on Monday February 01, 2016 @10:03AM (#51413429)

    It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...

    • Re:Huh? (Score:5, Informative)

      by Anonymous Coward on Monday February 01, 2016 @10:09AM (#51413477)

      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

  • by Dolda2000 ( 759023 ) <fredrik@dolda2[ ].com ['000' in gap]> on Monday February 01, 2016 @10:07AM (#51413463) Homepage

    so for now there is no good solution to avoid potentially bricking your system

    Have you tried not running rm -rf /?

  • I always run sudo \rm -rf That is the way to do it, you whippersnappers.
  • ...Systemd developers have rejected mounting the EFI variables as read-only...

    So the sane solution is rejected because the underlying design is bad?

    • ...Systemd developers have rejected mounting the EFI variables as read-only...

      So the sane solution is rejected because the underlying design is bad?

      systemd isn't in the wrong here. If you make the UEFI variables read-only, you lock down the hardware.

  • by CajunArson ( 465943 ) on Monday February 01, 2016 @10:11AM (#51413505) Journal

    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.

  • by Anonymous Coward on Monday February 01, 2016 @10:12AM (#51413517)

    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.

    • by green1 ( 322787 )

      exactly, why not mount them read-only by default, with the ability to re-mount as read-write as needed?

  • by bill_mcgonigle ( 4333 ) * on Monday February 01, 2016 @10:16AM (#51413551) Homepage Journal

    The kernel dev who wrote the efi code says [twitter.com] 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.

  • by Anonymous Coward on Monday February 01, 2016 @10:18AM (#51413561)

    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.

  • by LichtSpektren ( 4201985 ) on Monday February 01, 2016 @10:24AM (#51413601)
    There are too many imbeciles that will brick their system by typing in random terminal commands they found on the Internet, like fork bombs or using wget to download a trojan. rm -rf / is only the most famous of this kind of command. Then they will complain that Linux is too fragile and dangerous to use for new users, blah blah blah.

    I was thinking of a possible solution to this. Perhaps the distros meant for newbies (Ubuntu, Mint, elementary, Zorin, etc.) could lock by default the most well known terminal commands that fuck your system up. [howtogeek.com] When trying to execute them (even with root privileges), they will get something like "ERROR: This command is extremely dangerous. To execute, go to [distro's website].org/foobar." This page will have the password in order to bypass the lock, but only at the bottom of some text that explains exactly what will happen, and if you do anyway, that the distro has absolutely 0% liability to what will happen to your system.
  • by Lumpy ( 12016 ) on Monday February 01, 2016 @11:00AM (#51413963) Homepage

    When I hear Bricking it means I have to toss the hardware or whip out a JTAG or EEPROM programmer.

    Is this "bricking" real or just someone not understand what the word actually means and a initialize and reinstall of the OS will fix everything.

    • by dmomo ( 256005 ) on Monday February 01, 2016 @11:11AM (#51414067)

      It says in TFA that firmware is overwritten (and on a UEFI system, effectively the BIOS). So, simply reinstalling the f Operating system would not work in this case. Whether or not it's truly bricked, would depend on whether it's possible to re-flash that firmware. I'm sure that it IS possible, but how to do so would depend on how the machine is physically configured. Perhaps by putting some utility on a flash card? Perhaps by opening the computer case and doing something more pyhsical. So, no. Probably not bricked in the purest sense, but certainly more so in a practical sense than simply removing the OS.

  • by ssam ( 2723487 ) on Monday February 01, 2016 @11:08AM (#51414035)
    You also need the "--no-preserve-root" and to have a buggy motherboard UEFI implementation. The problem is that deleting stuff in /sys/firmware/efi/efivars resets some variables in the UEFI. If the implementation follows the spec then that is like doing a factory reset on your motherboard. For some poor hardware they fail to boot after this. The kernel already has some protection for some bad hardware, more will be added shortly ( https://gist.github.com/mjg59/... [github.com] ).
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Monday February 01, 2016 @11:10AM (#51414047)

    I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed. I couldn't believe it. RMSes worst nightmares come true, today. Un-fucking-believable.

    UEFI is just another machiavellian attempt at controlling our hardware from start to finish. It's basically the old TCPA [wikipedia.org] bullshit repackaged. How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me. I honestly am of the opinion that those who designed this freakin' insane UEFI BIOS crap and peddle it should be brought before court for malicious malpractice and willfully undermining computer security.

    UEFI in my book is definitely a reason not to buy the hardware using it.

    BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?

    • by Microlith ( 54737 ) on Monday February 01, 2016 @05:42PM (#51417045)

      Nothing quite like someone so prominently showing off their ignorance.

      I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed.

      I know the mode you speak of, it can be utilized effectively from Linux. Amusingly, it requires efivars to be writable as this article discusses.

      UEFI is just another machiavellian attempt at controlling our hardware from start to finish.

      Just like the BIOS was, right?

      How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me.

      Fortunately, that's not at all the case. You are right about one thing: it is totally beyond you.

      How come no one get's worked up about that?

      Because not everyone is as blatantly ignorant about it. Or if they are, they are kindly keeping their mouths shut until they learn more.

  • Bricked? (Score:3, Insightful)

    by MBGMorden ( 803437 ) on Monday February 01, 2016 @11:13AM (#51414089)

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

  • by PvtVoid ( 1252388 ) on Monday February 01, 2016 @11:19AM (#51414147)

    ... hitting yourself in the head with a hammer may cause headaches, or unconsciousness.

  • by JustNiz ( 692889 ) on Monday February 01, 2016 @12:57PM (#51414965)

    If the BIOS isn't even robust enough to use defaults for critical variables that can be deleted, then I'm gonna say this is OBVIOUSLY a problem with crappy BIOS code, not with the OS that ran the app that actually did exactly what it was told to do.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde

Working...