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.

[laloch]

@fandingo: I don't think anyone's going to implement (and merge) the overkill of file attributes to the efivarfs pseudo-file system.

[indrora]

Is there actually a reason to have efivarfs a thing by default? Why not use a wrapper that intercepts efi stuff and does The Right Thing™ -- this way grub-install just becomes efivar grub-install

[indrora]

@swiniopas There's some fun things you can do with SELinux.

[hewittc]

@aoighost You could easily get the same effect by running flashrom to erase or rewrite the system firmware. If a system is bricked by unlinking some files, though, it might actually belong in a trash bin.

[rysiekpl]

@hewittc I have never accidentally run flashrom; I have however accidentally run rm -rf /. Now, I have backups of most of my stuff, so rm -rf / is an annoyance at the worst... unless of course it turns out that now it can brick my system. How is that sane?

This is absurd. Mounting it read-only (or finding some other way of protecting it) is obviously The Right Thing to do.

[mattghali]

How is systemd getting crap for this instead of naming & shaming hw vendors shipping easily-brickable gear? Oh, right, it's systemd.

[rysiekpl]

@mattghali how is it okay for systemd not to try to protect the user from obvious hw vendors' fsckups, especially if it's actually quite easy?

Nobody said hw vendors are not at fault here. But that does not make it okay for systemd to keep mounting it read-write.

[mattghali]

seems by your logic, we should expect 'rm' to protect users from their own bad judgement, not systemd

[aoighost]

By your logic, a vulnerability doesn't matter because there are other ways
of doing similar stuff. By all means, let's leave a hole open. Why lock
your door if someone can throw a brick in your window.

On Fri, Jan 29, 2016, 6:42 PM Matthew Ghali notifications@github.com
wrote:

seems by your logic, we should expect 'rm' to protect users from their own
bad judgement, not systemd

—
Reply to this email directly or view it on GitHub
#2402 (comment).

[Mic92]

Should not the kernel prevent from deleting critical values, if it bricks the some faulty implementations?

[aoighost]

In a perfect world yes, but any vulnerability is fair game, and this is
asking for it

On Fri, Jan 29, 2016, 6:48 PM Jörg Thalheim notifications@github.com
wrote:

Should not the kernel prevent from deleting critical values, if it bricks
the some faulty implementation?

—
Reply to this email directly or view it on GitHub
#2402 (comment).

[mbiebl]

I don't believe the "rm -rf /" story @rysiekpl:

rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

[dv1]

How is systemd getting crap for this instead of naming & shaming hw vendors shipping easily-brickable gear? Oh, right, it's systemd.

@mattghali No, this is not "just because of systemd". There are certain areas where errors can have grave consequences, and which warrant additional protection. @mbiebl showed an example with the --no-preserve-root failsafe. Requiring some sort of additional explicit unlock for getting r/w access to the efivars is another. In a perfect world, hw vendors would not allow boards to be bricked like that, but we live in the real world, where this is an actual possibility. What is easier to do: requiring every single hw vendor to update their UEFI firmware, and every person owning UEFI boards to patch them? Or giving systemd a failsafe for efivars?

[mattghali]

let me know when you finish the operating system that protects you from yourself

[rysiekpl]

@mbiebl I happen to have been using systems that have rm a bit before --no-preserve-root came to be -- but see, this is a good example of a failsafe "just in case" somebody does something stupid by mistake.

@mattghali let me know when you submit a bugreport against rm to remove --no-preserve-root. This has to be a bug in your book, right?

[indrora]

@mattghali -- it does. rm won't trash / explicitly, to keep people from accidentally running rm -rf / -- you have to use --no-preserv-root and you have to confirm actions.

It won't stop /root/.. config/ though.

[Holzhaus]

@aoighost The Attacker has to be root to delete files from /sys anyway. If an evildoer manages to gain root privileges, he could just remount the efivars rw and then call rm.

So all fixes mentioned here can only protect from accidental deletion - not malicious intent.

[aoighost]

It's a vector none the less, you're just removing one more step

On Fri, Jan 29, 2016, 7:50 PM Jan Holthuis notifications@github.com wrote:

@aoighost https://github.com/aoighost The Attacker has to be root to
delete files from /sys anyway. If an evildoer manages to gain root
privileges, he could just remount the efivars rw and then call rm.

So all fixes mentioned here can only protect from accidental deletion -
not malicious intent.

—
Reply to this email directly or view it on GitHub
#2402 (comment).

[ethus3h]

Uhh, so... did the apps that were used before systemd cause this issue? If so, then why's everyone so angry about it now? If not, then why not just have systemd do whatever they do/did?

Also, I thought rm -rf / --no-preserve-root is a useful way to erase the disk quickly to prevent casual snooping by busybodies. Any app that can cause physical damage to hardware should ask first. If the rm goes through the kernel, why not just have the kernel pop up and ask if you want to do xyz with or without potential for hardware damage?

[neheb]

Am I the only one that thinks everyone is going full retard? To my knowledge, this is required for systemctl --firmware-setup reboot as well as using efibootmgr to change the next boot or whatever.

If anyone needs protection from idiocy, mount it as ro in /etc/fstab.

[felixphew]

@mbiebl try this one then:

$ rm -rf /*

[logannc]

rm should not cause hardware damage. No standard utility should. Argue all you want what constitutes standard, but rm is standard by literally everyone's definition.

[Baughn]

rm should not be able to cause hardware damage, because there should be no way to damage the hardware through software. This is a UEFI implementation bug, full stop, but the broken implementations aren't going away. It therefore makes sense to add roadblocks against users accidentally bricking their system.

I disagree that the best way is for systemd to avoid mounting efivarfs read-write, however. In cases like this, the most appropriate place to put a workaround is the kernel; that's its job, abstracting over hardware differences, and that very much includes broken hardware.

[AbstractBeliefs]

@Baughn does accidentally using the wrong if parameter with dd, thus ruining a disk with all-blank data count as hardware damage with a standard util?

[felixphew]

@AbstractBeliefs wiping a disk is not the same as bricking the BIOS. One requires an OS reinstall at worst, the other requires a hardware fix (replace / reprogram the BIOS), if a fix is even possible.

[Baughn]

@felixphew: I don't see that this bug has anything to do with systemd at all, though. It's entirely possible to mount efivarfs on a non-systemd distribution.

@AbstractBeliefs: Um, no? Were you arguing that it does?

[felixphew]

@Baughn The issue is not that efivars can be mounted. It's that systemd mounts efivars rw automatically.

[AbstractBeliefs]

@Baughn I'm mainly just wondering where the line gets drawn between "I trashed a disk" and "I trashed a BIOS" and what tools we're allowed to do it with.

[Baughn]

@AbstractBeliefs: I would draw it at whether or not a normal person can fix the problem by inserting a windows boot disk and hitting F8 during POST. Or whatever the relevant key is.

@felixphew: I don't see that particular behaviour as much of a problem. The problem is that buggy systems can be bricked; it could just as easily happen because because of, say, a bug in gummiboot or refind.

[ctrlcctrlv]

I agree with you in principle, but you know Linus's policy on dealing with "systemd's issues"... spew abuse for a few pages, and then close as "WONTFIX"

@felixphew It doesn't have to be a systemd issue. It should be simple to prove hardware damage outside of systemd by overwriting efivars. As I understand it even in systems without systemd it's still accessible to the kernel outside of the pseudofs...

[AbstractBeliefs]

@Baughn not entirely convinced by that line of reasoning. Stuff like writing GPIO into invalid states on embedded systems can trash lots of, say, motor driving kit in an automation system, but of course it's required that that GPIO be mapped in somewhere.

This obviously isn't an embedded scenario but really there's more depth to this than can be addressed by "standard utils shouldn't break hardware".

[Baughn]

@AbstractBeliefs: It's also a tempest in a teapot. How many different EFI implementations are actually known to brick themselves if you do this? And how likely is anyone to erase all the EFI vars by accident?

I'm here mostly because it's yet more evidence to me that the UEFI spec is too complex, if people are failing to properly implement it to even the degree of bricking. As for embedded systems, yes, naturally those tend to lack the safeties that are supposed to be built into modern PCs; all this SMM code and failsafes don't come free.

[woodruffw]

@AbstractBeliefs I think this case is distinct enough from GPIO/other embedded considerations to be a real concern.

Ideally, it should be as hard as possible for a user to actually brick their (commercial!) hardware from the operating system. Better safe than sorry.

[GrayHatter]

So... to summerise:

Request:

Please set the systemd default in a way that makes it harder to brick some BIOS on some motherboards?

Reply:

No, you can brick it other ways too

Does anyone have an argument other than "the way it is, is the status quo", or "you can break your system other ways"?

Because it seems to me that either systemd wants to make it easy to render a computer unusable (vs just an OS install). -OR- Is so unwilling to change as to be without any reason.

[rysiekpl]

@GrayHatter I think the only subject matter argument against changing the default to ro was:

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

However, there were a couple of solutions proposed to this here also.

[Matthew-Jemielity]

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]

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.

[poettering]

Locking this one. Note sure which peanut gallery site linked this...

[poettering]

I am deleting a number of insulting or completely off-topic messages now. Please find another place to troll, thank you.

[poettering]

To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.