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

[phoronix]

Phoronix: In A UEFI World, "rm -rf /" Can Brick Your System

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

http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory

[SpyroRyder]

I really am curious to know why anyone would actually rm -rf /. What is an advantage over booting into a secure live USB and formatting the partition? I honestly can't see why this would be something that you'd want to do.

[joolz]

I really am curious to know why anyone would actually rm -rf /.

By mistake

[AnonymousCoward]

By accident? Or remember that rm -rf /usr fiasco with bumblebee it could be /sys next time. Or just for shit and jiggles? Few users just wanted to see how far it could go before whole system crashed. I bricked one lenovo laptop with grub update so it is not limited only to rm.

[zorro]

With the GNU version of rm, the actual command is "rm -rf --no-preserve-root /", not easy to type by mistake...

[deragon]

I really am curious to know why anyone would actually rm -rf /. What is an advantage over booting into a secure live USB and formatting the partition? I honestly can't see why this would be something that you'd want to do.

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.

[plonoma]

I'm of the opinion "rm -rf /" should by default not touch any firmware/bios.
For touching firmware/bios, extra parameters/text/commands should be used to include the firmware/bios.
Have the normal commands ( without the extra parameter(s) ) only deal with the contents of filesystems/Logical Volumes by default.
Recursively deleting files should by default be limited to a logical volume of the file system.
Should make things much safer and easier to work with.

[unixfan2001]

Seems like there are a number of bugs regarding efivars.
Is there a way to emulate such failures?

Perhaps it would be a good idea to create a database documenting all the issues, publically shaming the hardware manufacturers into fixing their (U)EFI implementations.

With the GNU version of rm, the actual command is "rm -rf --no-preserve-root /", not easy to type by mistake...

Try "rm -rf /*"

And when I say "try it", I mean don't.

[ssokolow]

Question: Will installing via "legacy BIOS"-mode booting prevent access to EFI variables or is this just another reason beyond minimizing attack surface to track down either a pre-EFI motherboard or something coreboot/libreboot capable which I can flash without an EFI payload installed?

[bug77]

I'm of the opinion "rm -rf /" should by default not touch any firmware/bios.
For touching firmware/bios, extra parameters/text/commands should be used to include the firmware/bios.
Have the normal commands ( without the extra parameter(s) ) only deal with the contents of filesystems/Logical Volumes by default.
Should make things much safer and easier to work with.

Obviously. I cannot fathom how it escaped everyone till now that rm is best packaged together with a DB telling it which files it can delete and which ones it can't. And then you can simply hardcode the location of the DB into rm itself, so it doesn't delete it before it can read it. </sarcasm>