Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mount efivarfs read-only #2402

Closed
laloch opened this issue Jan 21, 2016 · 53 comments
Closed

Mount efivarfs read-only #2402

laloch opened this issue Jan 21, 2016 · 53 comments
Labels

Comments

@laloch
Copy link

@laloch laloch commented Jan 21, 2016

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
Copy link
Member

@poettering poettering commented Jan 25, 2016

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 poettering closed this Jan 25, 2016
@poettering poettering added the pid1 label Jan 25, 2016
@poettering
Copy link
Member

@poettering poettering commented Jan 25, 2016

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

@mpecio
Copy link

@mpecio mpecio commented Jan 26, 2016

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
Copy link

@graysky2 graysky2 commented Jan 26, 2016

(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
Copy link

@r3boot r3boot commented Jan 29, 2016

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

@laloch
Copy link
Author

@laloch laloch commented Jan 29, 2016

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

@dv1
Copy link

@dv1 dv1 commented Jan 29, 2016

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
Copy link

@jmtd jmtd commented Jan 29, 2016

via a hasty use of rm -rf /

Is there any other kind? :)

@LongHairedHacker
Copy link

@LongHairedHacker LongHairedHacker commented Jan 29, 2016

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
Copy link
Contributor

@floppym floppym commented Jan 29, 2016

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
Copy link

@dv1 dv1 commented Jan 29, 2016

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
Copy link

@indrora indrora commented Jan 29, 2016

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
Copy link

@fandingo fandingo commented Jan 29, 2016

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
Copy link
Author

@laloch laloch commented Jan 29, 2016

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

@indrora
Copy link

@indrora indrora commented Jan 29, 2016

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
Copy link

@indrora indrora commented Jan 29, 2016

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

@hewittc
Copy link

@hewittc hewittc commented Jan 29, 2016

@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
Copy link

@rysiekpl rysiekpl commented Jan 29, 2016

@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
Copy link

@mattghali mattghali commented Jan 29, 2016

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

@rysiekpl
Copy link

@rysiekpl rysiekpl commented Jan 29, 2016

@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
Copy link

@mattghali mattghali commented Jan 29, 2016

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

@aoighost
Copy link

@aoighost aoighost commented Jan 29, 2016

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
Copy link
Contributor

@Mic92 Mic92 commented Jan 29, 2016

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

@aoighost
Copy link

@aoighost aoighost commented Jan 29, 2016

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
Copy link
Contributor

@mbiebl mbiebl commented Jan 29, 2016

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
Copy link

@dv1 dv1 commented Jan 29, 2016

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
Copy link

@mattghali mattghali commented Jan 30, 2016

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

@rysiekpl
Copy link

@rysiekpl rysiekpl commented Jan 30, 2016

@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
Copy link

@indrora indrora commented Jan 30, 2016

@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
Copy link

@Holzhaus Holzhaus commented Jan 30, 2016

@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
Copy link

@aoighost aoighost commented Jan 30, 2016

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
Copy link

@ethus3h ethus3h commented Jan 30, 2016

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
Copy link
Contributor

@neheb neheb commented Jan 30, 2016

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
Copy link

@felixphew felixphew commented Jan 30, 2016

@mbiebl try this one then:

$ rm -rf /*
@logannc
Copy link

@logannc logannc commented Jan 30, 2016

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
Copy link

@Baughn Baughn commented Jan 30, 2016

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
Copy link

@AbstractBeliefs AbstractBeliefs commented Jan 30, 2016

@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
Copy link

@felixphew felixphew commented Jan 30, 2016

@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
Copy link

@Baughn Baughn commented Jan 30, 2016

@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
Copy link

@felixphew felixphew commented Jan 30, 2016

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

@AbstractBeliefs
Copy link

@AbstractBeliefs AbstractBeliefs commented Jan 30, 2016

@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
Copy link

@Baughn Baughn commented Jan 30, 2016

@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
Copy link

@ctrlcctrlv ctrlcctrlv commented Jan 30, 2016

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
Copy link

@AbstractBeliefs AbstractBeliefs commented Jan 30, 2016

@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
Copy link

@Baughn Baughn commented Jan 30, 2016

@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
Copy link

@woodruffw woodruffw commented Jan 30, 2016

@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
Copy link

@GrayHatter GrayHatter commented Jan 30, 2016

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
Copy link

@rysiekpl rysiekpl commented Jan 30, 2016

@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
Copy link

@Matthew-Jemielity Matthew-Jemielity commented Jan 30, 2016

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
Copy link

@annejan annejan commented Jan 30, 2016

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
Copy link
Member

@poettering poettering commented Jan 30, 2016

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

@systemd systemd locked and limited conversation to collaborators Jan 30, 2016
@poettering
Copy link
Member

@poettering poettering commented Jan 30, 2016

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

@poettering
Copy link
Member

@poettering poettering commented Feb 1, 2016

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.