Little warning: Deleting the wrong files may brick your Linux PC

Don't run rm -rf / as a laugh to clean your filesystem on a ham-fisted UEFI machine

Here's a friendly warning from El Reg: don't wipe the wrong directory from your Linux system, or you may end up bricking the computer. This has happened to people, we're told.

The directory in question is /sys/firmware/efi/efivars which is a special filesystem that presents the configuration settings for the computer's underlying UEFI firmware to the user. These configuration variables are used to control the way the motherboard firmware starts up the system and boots your operating system. Changing the files in this directory therefore changes these respective variables in the firmware.

If that efivars file system is mounted with read-write access, and its contents are deleted by a privileged user, then you'll blow away all of those settings. If your firmware code is badly written, it could be confused by the lack of settings during the next boot, and completely fail to start up.

This has apparently happened: someone said they managed to nuke their MSI notebook by wiping the efivars directory. The computer fails to get past even the power-on self-test, rendering it truly bricked, we're told. The user wanted to install a new OS, and so ran rm -rf / for laughs as root – a command that wipes all files from the file system, including ones in the efivars directory – and next found the machine unbootable.

Of course, running rm -rf / is dumb, but what's really dumb is bricking a machine by deleting the wrong file.

The problem surfaced in a systemd bug report that was quickly closed, but reanimated over the weekend by frustrated users. This problem isn't specific to systemd, though, it's just that systemd mounts efivars as read-write by default – any non-systemd Linux distro could choose to do the same.

The variables are presented as read-write so that, for example, the utility efibootmgr can do its stuff. Mounting the file system as read-only will break a bunch of tools.

Matthew Garrett, an expert on low-level code in Linux, said this issue isn't even specific to the open-source kernel – software running as administrator on Windows could trigger the same failure in the firmware, although we note that the danger is live on Linux systems that provide efivars as read-write by default.

On Monday, Garrett suggested a temporary kernel patch to block destructive write operations on efivars files. This is a workaround: the problem lies in clumsy firmware that falls over if it finds all of its runtime variables are missing.

"Systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware," Garrett tweeted. "I think you get to blame me instead."

For now, go easy on the sudo rm, OK? ®