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.


There were many community comments since then, but systemd developers have stood their ground and will not be mounting the EFI variables as read-only as they do write to the variables in some cases. Matthew Garrett who is also often involved in the UEFI Linux situation tweeted, "systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware. I think you get to blame me instead." It's not a systemd-specific issue at all but any distribution (or operating system for that matter) mounting EFI variables not as read-only.

Matthew says with about 20 lines of code on Windows, you can cause the same havoc. He points out that mounting EFI variables as read-only could break some user-space applications and isn't the solution to the problem. He does have some ideas for addressing this issue, but didn't elaborate or issue any new patches yet. For now, be forewarned you probably don't want to rm -rf / your Linux system if using modern UEFI hardware.


source

But why would you want to rm -rf / your system in the first place?

Tbh even without this "feature" it's not a good idea to use "rm -fr /"...

I can think of one reason: Curiosity.

If you actually want to see what happens in a safe way, I recommend loading a Live CD in a virtual machine; this way, you only damage the VM and not the system you care about.

(I also made this suggestion in another thread, but with recursive chmod, which is also destructive.)

Wait, they didn't fix that stupid bug?

I thought this would only be an issue for early UEFI systems.

On my system, if I type del c:\windows my system stops working, therefore I don't do that.

Isn't it actually "rm -rf / --no-preserve-root" if were talking about the GNU version of rm?

Why? rm -rf / will force (f) remove everything (/) recursively (r) as long as you run it as superuser.

I also do not get it. If you want to delete a drive then deleting the partition is easier.

*shrug*
only thing I can think of is being chrooted on a relative path and wanting to wipe that? who knows...

doesn't need to be "rm -rf /".

The problem is that deleting stuff in /sys/class/firmware/efi/efivars can brick your motherboard in some cases.
And given the big number of badly done BIOSes out there, it can be argued i think that such a critical thing lke EFI variables shouldn't be exposed to the filesystem where it just needs some buggy shell script to screw up your system.

You'd think that software engineers working in hardware would know better, and have isolated it directly.

I think the "--no-preserve-root" is a Debian-only option (and of course Debian derivatives too).

Actually, it is found on any modern distribution that uses GNU rm. On some BSD flavors, rm has a similar safeguard. Busybox rm, however, does not have this safeguard.

Also,
# -rf /*
will bypass the safeguard and wipe out every file anyway.