In A UEFI World, “rm -rf /” Can Brick Your System

Home » CentOS » In A UEFI World, “rm -rf /” Can Brick Your System
CentOS 22 Comments

Excerpt:
Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.

As a public service announcement, recursively removing all of your files from / is no longer recommended. On UEFI distributions by default where EFI variables are accessible via /sys, this can now mean trashing your UEFI implementation.

There is this systemd bug report requesting that UEFI variables be mounted as read-only by default. Lennart Poettering had initially responded and simply said, “Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. The ability to hose a system is certainly reason enought to make sure it’s well protected and only writable to root. But beyond that: root can do anything really.” He then closed the ticket.
— end excerpt –

22 thoughts on - In A UEFI World, “rm -rf /” Can Brick Your System

  • Once upon a time, m.roth@5-cent.us said:

    Did someone think running “rm -rf /” is a good idea?

    This has zero to do with systemd. This is a by-product of how the kernel driver and user-space tools for EFI are implemented. The kernel driver exposes EFI variables in a writable sysfs filesystem, and so that’s how the user-space tools set/update/delete the variables. Trying to force a change on that interaction from an intermediary is just wrong. If the maintainers for the EFI-related code think it should change, they’ll need to coordinate that change between the kernel and user-space.

    The bigger issue is that there is apparently some UEFI implementations that can’t handle certain variables being deleted or overwritten. Yes, that could happen from an errant rm, but there are other ways that could happen. Vendors that can’t recover in some way (like BIOS CMOS
    corruption can be recovered with a jumper) should be named-and-shamed as well as potentially blacklisted in some way in the EFI driver.

  • Quote from one of the people who commented on that article:

    QUOTE:

    You have this in a script: rm -rf “${DIRECTORY}”/

    Now, you have a bug in the script and ${DIRECTORY} is not initialized. You then get rm -rf / executed. One should always ensure that DIRECTORY is not empty before running this. Or better, never end with /. If you have rm -rf “${DIRECTORY}”, then only rm -rf gets executed, causing rm to fail since no file/directory is provided. END OF QUOTE

  • Yes, I kind of like “rm -rf /”. If my memory doesn’t fail me, long ago it was one of the tricky questions in sysadmin exam (not that anymore if I
    read what you, Michael, write further correctly…). Anyway, let’s imagine we are back then, then what

    rm -rf /

    will do you your system? How dramatic this command is?

    Well, it definitely will obliterate your /etc with all your settings. Then it will start deleting /dev, and once it deletes the block device your root filesystem “/” lives on, all trouble ends there. So, you just take your drive, and you will be able to mount on different machine /home,
    /usr, /var and what’s left of your / partition. /etc is gone, bit this only as dramatic as it gets (thanks for alphabetical order the command follows).

    Sorry about long spam message, everybody. I just so liked that tricky question from my past, I couldn’t hold myself.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • As much as I don’t like systemd, it has NOTHING to do with system and everything to a poor admin or newbie blindly following others advice.

    My suggestion is to ALWAYS fully qualify *ANY* directory you want to rm -rf, period.

    I speak from experience. Years ago had a script that would cd into a directory and then rm – rf * it. Problem started when I accidently deleted said dir and the PREVIOUS dir was /. Needless to say, the server was happily committing suicide before I figured out the problem.

    Lessons learned:
    1. Fully qualify ANY rm -rf command
    2. Make sure you always have good backups, I did!
    3. I became really, really good at disaster recovery :)
    4. Upper Management WILL get cranky over an event like this!

    Just my 2 cents worth…

    Richard

  • I just discovered that I couldn’t even re-cite alphabet correctly today:
    it is /bin that you loose, but /etc alphabetically goes after /dev, so will not even loose your /etc, all you will need it to restore portion of your /dev and the whole /bib (which you can do easily if you have “twin”
    system around…)

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • wait. would deleting the inode /sys/(whatever) actually modify UEFI
    memory? sure, writing to those inodes could do all sorts of harm, but deleting the inodes in the /sys filesystem, I’m not so sure this isn’t a tempest in a teapot so to speak.

  • so it will delete inodes there… does that damage the EFI
    hardware? I would think you’d have to open files and write data to actually modify the EFI stuff.

    my only C7 systems right now are VMs which don’t have uefi, so I can’t look and see what all this stuff actually is.

  • John R Pierce wrote:

    Yeah, I don’t think we really know, until someone’s willing to brick a many-thousand-dollar server….

    mark

  • I’m pretty sure none of that is correct. Once “rm” launches, all of the libraries and files that it needs are memory mapped and reference counted, so they’re going to remain available while it removes the entire filesystem structure.

    Spin up a VM and try it out.

  • Will doing

    rm -rf /

    actually delete anything in /sys? IMHO, not. The above command first will get to removing /dev, and it will delete /dev/sda1 or whichever device /
    filesystem lives on. And after that the command will fail, as there will be nothing accessible under / on that system after device root filesystem
    “/” lives on will be deleted. So, IMHO, that nasty command will never get to /sys, so all related to UEFI vars controlled through /sys filesystem will stay as they are. You will brick the box, but only in a sense you will have to restore /boot on your hard drive and /bin which these days is symlink (on CentOS 7), so actual content of /usr/bin where symlink points will stay intact. And portion of /dev – whatever alphabetically is before root filesystem device.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Yes, it will. Probably. It’s possible that it’ll hang on some of the files in /proc if it gets to that directory before /sys, but that’s largely a matter of chance.

    Access to your filesystems doesn’t depend on the device nodes after they’re mounted. You can remove all of the nodes in /dev, and your filesystems remain available. Spin up a VM and test it. I promise, it works.

    rm doesn’t process files in alphabetical order. It processes them in directory order, which is unpredictable.

  • All true, except for: to actually write stuff permanently to hard drive
    (that is modify whatever the content of hard drive is) the system needs to access /dev/sda1 (I call from now /dev/sda1 device which “/” filesystem lives on), and once /dev/sda1 is deleted there will be no further hard drive write operations. There will be no way for system to access anything under /, which will cause “rm” command to fail fataly. I will kickstart install CentOS 7 in a moment and will do exactly this:

    cd /

    rm -rf /

    (the first command is to avoid even “can not get CWD”, which shouldn’t matter ;-)

    So, I’ll see in a moment how much I’ll loose on the drive, and will it or will it not be sufficient to rsync /boot from “twin” box, and restore /bin symlink. Will get back with either “crap, indeed I was wrong”, or “yes, even on latest CentOS 7 system it is still so”. Whatever the result is, I’ll enjoy this experiment. Thanks for giving me incentive to do it!

    Incidentally, let me know if there is anything I should change in my experiment for that to give us more definite answers that just “oh, look, I still have /etc, /home, /usr… intact on hard drive”. What specifically should I do to learn that in a course of this command /sys was never touched? Any ideas?

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Yeah, that can happen, but I remember being taught that was an extremely bad scripting practice back in 1998 when I took my first Linux class.

  • Once upon a time, Valeri Galtsev said:

    Incorrect. Once the filesystem is mounted, the kernel access doesn’t go through the filesystem /dev node, similar to how once rm is running, it doesn’t need the /lib64/libc.so.6 node.

  • In article <75D47FDC6A99F24F87A6465BAF326D5018C50F69@COLUMBA02.user.uu.se>, Sorin Srbu wrote:

    I think the point is that hitherto, if you kill a system with “rm -rf /”, you can still do a re-installation from scratch. If I understand correctly what people are saying, killing the UEFI stuff stops you ever being able to do a re-install on that box. Is that correct? Is there no way to do a factory reset of the BIOS?

    Cheers Tony

  • Once upon a time, Frank Cox said:

    Just to clarify: this appears to be a problem with some particular buggy UEFI implementations; this is not a universal problem with the UEFI
    design or anything. It is unclear (just “some MSI boards”) which models/revisions/etc. have this particular problem. There have been other isolated UEFI implementation problems before (some Samsung laptops for example, with a particular UEFI version and Linux kernel driver version plus a samsung-laptop driver enabled).

    This isn’t meant to diminish the impact; certainly UEFI is proving to be problematic in ways the BIOS wasn’t (although the early days of “IBM
    compatible BIOS” implementations also had weird issues from time to time).

LEAVE A COMMENT