Mount efivarfs read-only

[laloch]

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.

[poettering]

Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system.

The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really.

[poettering]

(note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")

[mpecio]

I just wanted to point that you can't really screw your machine by accessing /dev/sda, unless maybe by writing

rm -rf /sys/firmware/efi/efivars/

to some block which happens to contain a shell script.

It seems that currently UEFI users are living one rm or echo ... >/sys/... accident away from bricked motherboard.

And reporter's case isn't isolated, see page 43 here.

[graysky2]

(note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro")

I wonder if this is considered a best practice post-install? A user reported that he rendered his PC "bricked" via a hasty use of rm -rf / since /sys/firmware/efi/efivars/ was mounted rw by systemd apparently without his knowledge.

[r3boot]

@mpecio dd if=/dev/zero of=/dev/sda will most definetely destroy the contents of your /dev/sda ;)

[laloch]

@r3boot: yes, but you don't usually have to desolder and reprogram the disk controller afterwards.

[dv1]

Making this read-only by default also sounds like the better option to me. The /dev/sda thing is not comparable, since as @laloch said, you don't end up with hard-bricked hardware by wiping /dev/sda.

Well, there are tools that actually want to write it.

Such tools won't be used by 99,9% of all people. And those who do need to use it should be aware that they need to explicitely mount it read-write first.

[jmtd]

via a hasty use of rm -rf /

Is there any other kind? :)

[LongHairedHacker]

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.

[floppym]

Such tools won't be used by 99,9% of all people.

Anyone who runs grub-install is going to encounter an error when efibootmgr fails to write to this filesystem. I don't think it's as uncommon as you say.

[dv1]

Anyone who runs grub-install is going to encounter an error when efibootmgr fails to write to this filesystem. I don't think it's as uncommon as you say.

Okay, then I'd remount it read-write before the write, and read-only afterwards again. I am even fine with some other sort of safeguard, as long as there is any.

Just because a control room is accessible, it does not mean that we should not have protective lids over buttons there that can do really bad things if pressed.

[indrora]

I'm going to leave this here:

rm -rf /opt/matlab /sys/

We haven't seen anything like... Oh wait... When I need a clean /usr I just install bumblebee...

I'm voting "make it to by default" -- running grub-install or such should be an edge case of "remount, do the thing, clean up, remount."

[fandingo]

Just throwing this out there...

Why are the only options ro or rw? We do have some other access controls. Maybe efivarsfs should automatically mark all files immutable at boot, but the actual file system is rw. Tools that need to manipulate the vars can make them mutable temporarily. That seems better than remounting a file system.

The granularity would be a major benefit. I can't say I'm enthusiastic about a binary ro/rw switch that will entirely disable this protection.