Running "rm -rf /" on linux will brick almost any UEFI based system to some degree

[Syntaxvgm]

Remember that old joke about dragging "My Computer" to the Recycling bin in windows? 

Well here's the spiritual equivalent! 

Welcome to the Linux "Every fucking thing is a file, including you" approach. You remember Tron? Yah, well, Flynn was a file. 

Seriously, it works. I tried it with one of my 'older' boards.  (Still pretty recent) It works. Don't try it. (It's a dual UEFI system, one of those gaming boards that lets you recover from this, so I'm pretty sure it'll be fine)

Matthew Garret says you get to blame his handy work for this one. 

 

https://github.com/systemd/systemd/issues/2402

Quote

Mounting efivarfs read/write by default can lead to accidental deletion of the EFI variables. It was already reported on Arch Linux forums, that running 'rm -rf' over a directory structure with mounted efivarfs did actually "hard-brick" some MSI notebook.

Like mentioned int eh above post, most systems with a good implementation SHOULD be recoverable, but a lot of newer laptops are vulnerable and not recoverable. (Need to replace motherboard)

[Covalent]

Quote

So I'd like add some points to the discussion here since some people seem to be only partially aware of the consequences of this problem:

Point 1: 
Deleting /sys/firmware/efi/efivars/ should thrash your EFI configuration,
but in a properly implemented EFI this should be recoverable.

Point 2:
There is some pieces hardware out there with broken/poorly implemented EFI,
which will can be permanently bricked by doing standard conform stuff to them.
See for example the case where Ubuntu bricked some Samsung laptops by storing additional data in some EFI memory.
This behaviour was fine by standard but broke this particular implementation.

Point 3:
Running anything as root that writes to /dev/sda will destroy your partition table and/or filesystems.
That's bad especially if you have no backup, but after partitioning, creating new filesystems and reinstalling your OS your machine will work again.
So you can recover from it by booting some other media and redo your installation.

Point 4:
Thrashing your EFI is a whole different kind of problem.
In the worst case you won't be able to do anything with the machine as it will not get to POST.
No booting from an other media, no entering some EFI utility to fix missing stuff.
A that point your computer is a really expensive paperweight.

That is a lot worse than having to reinstall your OS, at least from my perspective.
In the one reported case this was covered by manufacturers warranty,
but I would not want to rely on that.

So I have to admit in an ideal world where all EFI implementations are up to standard,
this should not be more dangerous the exposing /dev/sda to root,
since your machine would still be able to boot to something allowing you to recover it.
Obviously we are not at this point yet.

For now I would like to see some additional safeguard in place here.
Like mounting the folder ro by default and remounting it rw if something needs to write to it.

Found this in the github issue, and thought it would provide some insight into the issue.

[dmegatool]

Quote

Mounting efivarfs read/write

To Linux beginners like me, what's that used for ? 

[jessejarvi]

Tested this on a HP Elitebook Folio that was going to rubbish bin at work today. It did brick it. I'm really suprised actually.

[Syntaxvgm]

38 minutes ago, jessejarvi said:

Tested this on a HP Elitebook Folio that was going to rubbish bin at work today. It did brick it. I'm really suprised actually.

Poor laptop! 

I told you I tested it already

[lubblig]

I was casually browsing reddit earlier and saw a post on /r/hacking. A guy wanted to know how to hack instagram.......

The response he got was to run this command in terminal and when he presumably did so he stopped responding... Not sure if he really did it and bricked his pc or just stopped caring about the thread.. Hopefully he didn't brick his computer though.. That cannot be fun..

 

link: https://www.reddit.com/r/hacking/comments/43h44h/how_do_to_hack_intsagram/

poor guy if he actually did it...

[Syntaxvgm]

6 minutes ago, lubblig said:

I was casually browsing reddit earlier and saw a post on /r/hacking. A guy wanted to know how to hack instagram.......

The response he got was to run this command in terminal and when he presumably did so he stopped responding... Not sure if he really did it and bricked his pc or just stopped caring about the thread.. Hopefully he didn't brick his computer though.. That cannot be fun..

 

link: https://www.reddit.com/r/hacking/comments/43h44h/how_do_to_hack_intsagram/

poor guy if he actually did it...

Meant to mark this funny and marked it friendly on accident. This is too complicated. 

[suicidalfranco]

36 minutes ago, lubblig said:

I was casually browsing reddit earlier and saw a post on /r/hacking. A guy wanted to know how to hack instagram.......

The response he got was to run this command in terminal and when he presumably did so he stopped responding... Not sure if he really did it and bricked his pc or just stopped caring about the thread.. Hopefully he didn't brick his computer though.. That cannot be fun..

 

link: https://www.reddit.com/r/hacking/comments/43h44h/how_do_to_hack_intsagram/

poor guy if he actually did it...

top level trolling over there

[Jade]

Any good distro / one not for powerusers won't let you 'rm -rf /' without --no-preserve-root. And powerusers know not to do it anyway.

[jessejarvi]

1 hour ago, Syntaxvgm said:

Poor laptop! 

I told you I tested it already

I just had to try it This is such a fuck up

[Syntaxvgm]

3 minutes ago, Jade said:

Any good distro / one not for powerusers won't let you 'rm -rf /' without --no-preserve-root. And powerusers know not to do it anyway.

I don't think anyone will do this by accident, but you shouldn't be able to do this at all. In my opinion at least. 

[Jade]

Just now, Syntaxvgm said:

I don't think anyone will do this by accident, but you shouldn't be able to do this at all. 

Albeit true, you should fault the motherboard manufacturers for implementing EFI poorly, as well.

[Syntaxvgm]

1 minute ago, Jade said:

Albeit true, you should fault the motherboard manufacturers for implementing EFI poorly, as well.

Yah all can be avoided with a "Dual bios" as it's called. 

[420istoday]

5 minutes ago, Syntaxvgm said:

Yah all can be avoided with a "Dual bios" as it's called. 

Or in AsRock's case, swappable bios chips, which should be standard on all motherboards since bios flashes are pretty much necessary for some compatibility.

[PCgamer324]

didn't even know efi was accessible after boot.  guess it has to be for in-OS flashing.  Never seen it in Fdisk though...  

 

anyone want to explain what -rf does. man rm doesn't even list it...

[Syntaxvgm]

2 minutes ago, PCgamer324 said:

didn't even know efi was accessible after boot.  guess it has to be for in-OS flashing.  Never seen it in Fdisk though...  

 

anyone want to explain what -rf does. man rm doesn't even list it...

http://linux.die.net/man/1/rm

-r is recursive, -f is force

[jakkuh_t]

Please don't ever do that. rm -rf isn't very good practice.

[PCgamer324]

2 minutes ago, Syntaxvgm said:

http://linux.die.net/man/1/rm

-r is recursive, -f is force

ah okey

 

forgot how arguments are kinda mushed together in RM...

 

"/" specifies all directories then I assume?  Or at least everything in your working directory?

[Syntaxvgm]

2 minutes ago, PCgamer324 said:

ah okey

 

forgot how arguments are kinda mushed together in RM...

 

"/" specifies all directories then I assume?  Or at least everything in your working directory?

the latter I think 

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.

http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/849201-in-a-uefi-world-rm-rf-can-brick-your-system?p=849215#post849215

In addition, at least on the machine I did it on, I had to type 

rm -rf --no-preserve-root /

to make it work, i think that has to do with the specific implementation of RM 

[PCgamer324]

reasons why mac users shouldn't be paranoid AF when installing downloaded stuff now?

Imagine if entering your password to "install" authorized this sudo action...

[dmegatool]

2 hours ago, PCgamer324 said:

"/" specifies all directories then I assume?  Or at least everything in your working directory?

/ would be the top level. In Windows, I guess that would translate to MyComputer:/ (not a partition like c:/).

So, it's really like that gif xP
 

[Fetzie]

This isn't news. It has been a command since unix was first released.

[patrickjp93]

2 minutes ago, Fetzie said:

This isn't news. It has been a command since unix was first released.

What is news is that it wipes out your UEFI capability altogether in some instances.

[Yummychickenblue]

4 hours ago, lubblig said:

I was casually browsing reddit earlier and saw a post on /r/hacking. A guy wanted to know how to hack instagram.......

The response he got was to run this command in terminal and when he presumably did so he stopped responding... Not sure if he really did it and bricked his pc or just stopped caring about the thread.. Hopefully he didn't brick his computer though.. That cannot be fun..

 

link: https://www.reddit.com/r/hacking/comments/43h44h/how_do_to_hack_intsagram/

poor guy if he actually did it...

I'm pretty sure it's fake since his user profile shows posts from after that topic.

[Fetzie]

2 minutes ago, patrickjp93 said:

What is news is that it wipes out your UEFI capability altogether in some instances.

Although if I had a PC running Linux that had public access I'd remove wx permissions for all users and groups but root / superuser on all folders and their contents but /home/user/. Not like they'd need to do that anyway.