Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

It happens rarely, but actually I totally agree with Lennart on this one. Maybe not for the very same ultimate reasons, but nevertheless, I agree.

Being able to brick hardware through a very oftenly used action (unliking a filesystem entry) throws us back into the times where one could damage display devices beyone repair by feeding them scan frequencies outside their operational range or by destroying hard disks by smashing the heads into a parking position outside of the mechanical range. We left those days behind us some 20 years ago: Devices got smart enough to detect potentially dangerous inputs and execute failsafe behaviour. It's just reasonable to expect this from system firmware.

When talking about (U)EFI variables we're not talking about firmware updates, which are kind of a special action (and even for firmware updates its unacceptible that a corrupted update bricks a system¹). Manipulating (U)EFI variables is considered a perfectly normal day-to-day operation and the OS should not have to care about sanity checks and validity at boot time. (U)EFI is the owner and interpreter of these variables, so it is absolutely reasonable to expect the firmware to have safeguards and failsafe values in place.

IMHO (U)EFI is a big mess, a bloated mishap of system boostrap loader. And I'm totally against trying to workaround all the br0kenness in higher levels. The more and often systems brick due to the very fundamentals of (U)EFI being so misguided, the sooner we'll move on to something that's not verengineered.

----

¹: Just to make the point: When we developed the bootstrap loader for our swept laser product we implemented several safeguards to make it unbrickable. It's perfectly fine to cut the power or reset the device in the middle of a firmware upgrade. It safely recovers from that. Heck, the firmware in flash memory could become damaged by cosmic radiation, the bootloader would detect it and reinstall it from a backup copy in secondary storage.

Aside: I misread "swept laser" as "sweet laser" and was really bummed you didn't include a link to the Kick Starter for whatever project that would have been.

I completely disagree. I looked at the patch above. I personally don't like. mounting efivars rw is akin to mounting boot rw by default.

A sane linux distro will mount it ro and switch to rw whenever need. Defaulting to rw efivars is, excuse the language stupid.

I've done a fair share of efi debugging even removing some of the variables that the kernel will now protect you from breaking.

If the issue is that users should be able to remount efivars as rw whenever needed then that should be addressed, not prevent you from doing stuff to it because there is a rogue init system doing crazy stuff.

EDIT: BTW, i don't think systemd does anything besides write to the various Boot* variables, but I may be wrong. I don't see why that can't be addressed with a remount. If you replace the boot.efi you still have to remount the efi partition anyway.

While Matthew may be right that there is an issue that needs to be addressed, but in one of his tweets he basically says the kernel should fix it because tooling isn't and bioses suck. Well, maybe tooling should be forced to fix it.

or from the issue:

    Matthew-Jemielity commented 24 days ago
    What needs efivars mounted at all anyway? So far I've seen:

    grub
    systemctl --firmware-setup reboot
    efibootmgr
    Since those likely need superuser, couldn't they handle (un)mounting it themselves?
    
    @annejan
    annejan commented 23 days ago
    As long as distribution that are aimed at consumers remount it ro and on updating kernels wrap grub with remount this is a complete non-issue.

I can see the point that you shouldn't make otherwise-undesirable OS changes to accommodate incompetent hardware designers. The thing is, I'm not convinced that it this is undesirable: mounting efivars read-only by default seems like a completely reasonable thing to do, even absent this particular hardware issue. BIOS setting are important and rarely need to be changed, and anything that doesn't have the privileges to unlock efivars probably shouldn't be messing with it anyway.

> I personally don't like. mounting efivars rw is akin to mounting boot rw by default.

No, it's not the same. Mounting `/boot` rw by default does not put your system in the danger of getting damaged beyond repair. If you hose the boot partition you can always start a recovery system (live Linux or similar) to repair the damage.f

But if deleting efivars renders a system inoperable on a firmware level you're essentially SOL, save for rewriting the contents of the system firmware flash using an external programmer and a clean image. That is an absolutely inacceptable situation. The year is 2016 and hosing a firmware by writing malformed values into the firmware API is, simply put, a software vulnerability that allows to permanently DoS a system. As such this is a security issue that must be fixed at where the security issue happens. And in case of efivars the issue is that certain input is not properly validated and/or sanitized. If a system firmware can not properly start with certain variables being unset or removed or set to invalid valued, its should be a implementation requirement to validate input on such variables before executing the change.

> Defaulting to rw efivars is, excuse the language stupid.

It probably it. But it's not the responsibility of the OS to sanitize values that are not intended for being used by the OS. efivars are intended to be used by (U)EFI and hence it's the (U)EFI implementation's task to properly sanitize access to them.

Essentially we're talking Bobby Tables here, just with a different API.

> I totally agree with Lennart on this one.

There's a certain rich irony that Lennart is being flogged for following the Unix tradition (root can do anything, including blow up their monitor with bad X configs); that his detractors are suggesting userland tools manage their hardware (normally the job of the kernel in a Unix system); that systemd ought to be expanded to manage hardware (after years of complaining it's too big), presumably by adding whitelisting capabilities and a database of known-good/known-bad UEFI implementations.

I guess at least it demonstrates how utterly unhinged some people become when his name is attached to anything.

> mounting efivars read-only by default seems like a completely reasonable thing to do, even absent this particular hardware issue.

It's perfectly reasonable to ro mount efivars. But doing so must not be the workaround to fix an security issue (and yes, this is a security issue) in (certain implementations of)(U)EFI. Just to make clear why this is an security issue: Security rests of three pillars:

- availability - confidentiality - authenticity

Rendering a system unusable (DoS-ing it) it an attack on availability. And speaking of security, if the goal is sabotage and causing large financial damages, then being able to permanently brick a system in case of a privilege escalation (there's nothing stopping UID=0 from remounting rw efivars) is pretty bad; and no, the implemented fixes in the efivars kernel code don't help, because an attacker can still mount a custom kernel module which will talk to the respective efivars code directly circumventing sanity checks (or directly talk to (U)EFI without using the efivars code).

I remember the days when a single virus destroyed practically every motherboard for my local government. They had to throw away every machine and replaced it, costing the Swedish government several millions in early 2000 (https://en.wikipedia.org/wiki/CIH_%28computer_virus%29), and according wikipedia caused globally something around $1 billion US dollars in commercial damages.

A virus should not be able to destroy the system BIOS. The problem with efivars is illuminating a vulnerability, not a feature for "doing stuff". I would expect to see this used in the wild if left unfixed, especially the next time we hear about a remote vulnerability that permit arbitrary memory execution.

> (U)EFI implementation's task to properly sanitize access to them.

If the implementation is bad (which it is), that doesn't excuse reckless userland software that refuses to acknowledge flaws in the firmware.

There's a layer between userland and firmware where those things should be handled, and indeed everyone agreed that it should be handled in the kernel

Saying that Lennart is wrong has become a rather popular sport, let's not go overboard to say it even when he's right by all accounts.

> I guess at least it demonstrates how utterly unhinged some people become when his name is attached to anything.

He earned it with his hard work with the Linux community.

By propelling linux process supervision into the 21th century, change is scary

No. That one earned him adoption of his init.

Actually Lennart working for RedHat is what gave systemd serious traction. If it came to 21st century software, there are numerous modern init systems around (dependency driven, fast) that largely predate systemd. If any of those systems had been widely adopted by now it would be probably far ahead of systemd in feature set.

OpenRC is what got closest to be the replacement SysV-Init, just by its qualities and market share. But other, nicer systems exist, but they never found wide adoption because the main distributions didn't let go of SysV.

Now Lennart claims all the bragging rights, but people who used modern init systems before it was cool know better (there are a lot of Lennart opponents among those, BTW).