Distributions

Bricking systems using rm

Deleting all files starting at the root (i.e. rm -rf /) is generally ill-advised; it is almost always a mistake of some sort. But, even if it is done intentionally, a permanently unbootable system—a brick—is not expected to be the result. The rm command can cause all of the Extensible Firmware Interface (EFI) variables to be cleared; due to some poorly implemented firmware in some systems, that can render the device permanently unable to even run the start-up firmware.

The problem was first reported to the Arch Linux forums in a thread that has been moved so that it is only available to registered users. Essentially, the user "9233" reported running:

    rm -rf --no-preserve-root /

The reason given was to "get rid of the pretty bloated Arch installation" on an MSI notebook. As noted in the post, there are plenty of other ways to accomplish that (e.g. reformat the partition), but that was the one chosen. After doing so, the system would no longer even start up the firmware after a power cycle, thus it couldn't boot or even allow the firmware settings to be changed.

Participants in the thread rapidly narrowed it down to the EFI variables that are accessible via the /sys/firmware/efi/efivars/ directory. These variables are stored in non-volatile RAM (NVRAM) on the motherboard of the system. Even though the Universal EFI (UEFI) specification clearly states that wiping all of the boot variables should still result in a bootable system, the UEFI implementation on the laptop did not conform. When those variables were deleted by the rm command, the laptop would no longer even reach the power-on self-test (POST) that is the first step in booting.

Some in the thread (and in discussions at Hacker News and reddit) tried to blame systemd for the problem, but the systemd bug filed was quickly closed by Lennart Poettering. Systemd needs the ability to write to EFI variables to reboot the system in some scenarios, so it mounts the efivarfs as a read-write filesystem on /sys/firmware/efi/efivars as he noted in a later message. He also pointed out that the filesystem can be remounted read-only with a change in /etc/fstab.

None of that completely ended the systemd squawking, but it was clear to most that the real problem lies in the UEFI implementation. That broken firmware may not be fixed soon—if ever—so the conversation turned to how to work around the problem. There were some who advocated mounting efivarfs as read-only until something needed to write to it. Poettering seemed adamant that systemd would not do so, but distributions could certainly remount efivarfs as read-only, though it might require changes to systemd for the reboot scenario.

But the kernel is traditionally the place where broken hardware is "fixed", as others in the thread argued. To that end, Matthew Garrett offered up a quick fix that simply disallowed deleting most UEFI variables. "For a short-term fix, let's just block deletion of most variables while we figure out a better approach." A longer-term solution has also been proposed by Peter Jones (with an Acked-by from Garrett).

Jones's approach is to make most of the UEFI variable "files" in efivarfs immutable, except for a whitelist of those variables that are known to be safe (at least so far). Making the files immutable means they cannot be changed, but root (or processes with the CAP_LINUX_IMMUTABLE capability) can use the chattr -i command to make them mutable again. The idea is to protect these variable files from programs like rm, but to allow programs that do need to change them the ability to do that. That way, accidental (or even intentional) deletions will be prevented unless an administrator makes a conscious effort to circumvent the restrictions.

While the real problem lies in the firmware implementation, it is not uncommon for the kernel developers to try to find ways to avoid giving users unpleasant surprises. Bricked laptops certainly qualify. One can wonder about whether it is sensible to delete all files from the root, but there is no question that it shouldn't lead to unusable hardware—or even warranty service.

It should be noted that any attackers who get root access to a system that has this flaw can exploit it. They can, of course, do lots of other destructive things, but permanently disabling the hardware is not exactly expected. Those who have affected systems should be clamoring for a firmware update from their manufacturers. Unfortunately, the only way to figure out if a system is impacted may be to try to brick it, which is likely to make folks just a little shy about doing so.

Comments (58 posted)

Distribution quote of the week

-- Lars Wirzenius

Comments (4 posted)

Ubuntu 15.04 End of Life

Ubuntu 15.04 (Vivid Vervet) reached its end of life on February 4. The supported upgrade path from Ubuntu 15.04 is via Ubuntu 15.10.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 647 (February 8)
• openSUSE Tumbleweed review (February 5)
• Tails report (August 2015 — published February 4)
• Ubuntu Kernel Team newsletter (February 9)
• Ubuntu Weekly Newsletter, Issue 453 (February 7)

Comments (none posted)

FreeBSD quarterly report

FreeBSD presents its quarterly report for the fourth quarter of 2015. "Efforts to bring our BSD high standards to new architectures continue, with impressive work on arm64 leading to its promotion to Tier-2 status and a flurry of work bringing up the new RISC-V hardware architecture. Software architecture is also under active development, including system startup and service management. A handful of potential init system replacements are mentioned in this report: launchd, relaunchd, and nosh. Architectural changes originating both from academic research (multipath TCP) and from the realities of industry (sendfile(2) improvements) are also under way. It is heartening to see how FreeBSD provides a welcoming platform for contributions from both research and industry."

Comments (6 posted)

First Ubuntu Touch Tablet Brings Convergence at Last (Linux.com)

Over at Linux.com, Eric Brown looks at the newly announced Ubuntu Touch tablet. The hardware: "The Aquaris M10 is equipped with a 64-bit, quad-core, Cortex-A53 MediaTek MT8163A system-on-chip clocked to 1.5GHz, along with a high-powered ARM Mali-T720 MP2 GPU. The tablet ships with 2GB of RAM, 16GB flash, and a microSD slot." It is said to have 1920x1200 resolution and an 8 megapixel camera capable of HD recording. The interface will change to take advantage of larger displays and additional input devices (e.g. keyboard, mouse). "It appears that the upcoming Ubuntu 16.04 “Xenial Xerus” LTS release due in April will be the first true convergence release. According to PC World, it will still be optional, however, with a traditional Unity 7 build with X.org available alongside the newly converged Unity 8 with the new Mir display server. The new tablet, and Unity 8, will feature Ubuntu Touch’s Scopes interface, which presents frequently used content and services as an alternative to traditional apps. In addition to automatically changing the interface in response to new screens and input devices, Ubuntu is also providing convergence on the application development level. Developers are already developing single apps that can automatically morph into desktop, phone, and tablet formats."

Comments (20 posted)

Rosa Is a Real Powerhouse (LinuxInsider)

LinuxInsider reviews Rosa Desktop Fresh R7, which was released last month. "The Rosa distro's custom software is a big differentiator that sets Rosa apart from other purveyors of Linux, especially those using the KDE flavor. Some of the Rosa-specific features are turned on by default. Others are widgets you can add to the desktop controls. A nice touch associated with these Rosa-branded items is a modification to the panel bar across the bottom of the screen. The panel is redesigned to allow bigger icons. This function previously was unavailable for the KDE panel."

Comments (1 posted)