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

Comments

@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

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jan 25, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jan 25, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@mpecio

mpecio 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.

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

This comment has been minimized.

Show comment
Hide comment
@graysky2

graysky2 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.

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

This comment has been minimized.

Show comment
Hide comment
@r3boot

r3boot Jan 29, 2016

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

r3boot commented Jan 29, 2016

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

@laloch

This comment has been minimized.

Show comment
Hide comment
@laloch

laloch Jan 29, 2016

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

laloch commented Jan 29, 2016

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

@dv1

This comment has been minimized.

Show comment
Hide comment
@dv1

dv1 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.

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

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Jan 29, 2016

via a hasty use of rm -rf /

Is there any other kind? :)

jmtd commented Jan 29, 2016

via a hasty use of rm -rf /

Is there any other kind? :)

@LongHairedHacker

This comment has been minimized.

Show comment
Hide comment
@LongHairedHacker

LongHairedHacker 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.

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

This comment has been minimized.

Show comment
Hide comment
@floppym

floppym Jan 29, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@dv1

dv1 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.

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

This comment has been minimized.

Show comment
Hide comment
@indrora

indrora 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."

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

This comment has been minimized.

Show comment
Hide comment
@fandingo

fandingo 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.

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

This comment has been minimized.

Show comment
Hide comment
@laloch

laloch 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.

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

This comment has been minimized.

Show comment
Hide comment
@indrora

indrora 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 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

This comment has been minimized.

Show comment
Hide comment
@indrora

indrora Jan 29, 2016

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

indrora commented Jan 29, 2016

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

@hewittc

This comment has been minimized.

Show comment
Hide comment
@hewittc

hewittc 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.

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

This comment has been minimized.

Show comment
Hide comment
@rysiekpl

rysiekpl 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.

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

This comment has been minimized.

Show comment
Hide comment
@mattghali

mattghali 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 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

This comment has been minimized.

Show comment
Hide comment
@rysiekpl

rysiekpl 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.

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

This comment has been minimized.

Show comment
Hide comment
@mattghali

mattghali Jan 29, 2016

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

mattghali commented Jan 29, 2016

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

@aoighost

This comment has been minimized.

Show comment
Hide comment
@aoighost

aoighost 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).

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

This comment has been minimized.

Show comment
Hide comment
@Mic92

Mic92 Jan 29, 2016

Contributor

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

Contributor

Mic92 commented Jan 29, 2016

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

@aoighost

This comment has been minimized.

Show comment
Hide comment
@aoighost

aoighost 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).

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

This comment has been minimized.

Show comment
Hide comment
@mbiebl

mbiebl Jan 29, 2016

Contributor

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@dv1

dv1 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?

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

This comment has been minimized.

Show comment
Hide comment
@mattghali

mattghali Jan 30, 2016

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

mattghali commented Jan 30, 2016

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

@rysiekpl

This comment has been minimized.

Show comment
Hide comment
@rysiekpl

rysiekpl 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?

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

This comment has been minimized.

Show comment
Hide comment
@indrora

indrora 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.

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

This comment has been minimized.

Show comment
Hide comment
@Holzhaus

Holzhaus 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.

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

This comment has been minimized.

Show comment
Hide comment
@aoighost

aoighost 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).

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

This comment has been minimized.

Show comment
Hide comment
@ethus3h

ethus3h 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?

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

This comment has been minimized.

Show comment
Hide comment
@neheb

neheb Jan 30, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@felixphew

felixphew Jan 30, 2016

@mbiebl try this one then:

$ rm -rf /*

felixphew commented Jan 30, 2016

@mbiebl try this one then:

$ rm -rf /*
@logannc

This comment has been minimized.

Show comment
Hide comment
@logannc

logannc 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.

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

This comment has been minimized.

Show comment
Hide comment
@Baughn

Baughn 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.

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

This comment has been minimized.

Show comment
Hide comment
@AbstractBeliefs

AbstractBeliefs 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?

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

This comment has been minimized.

Show comment
Hide comment
@felixphew

felixphew 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.

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

This comment has been minimized.

Show comment
Hide comment
@Baughn

Baughn 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?

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

This comment has been minimized.

Show comment
Hide comment
@felixphew

felixphew Jan 30, 2016

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

felixphew commented Jan 30, 2016

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

@AbstractBeliefs

This comment has been minimized.

Show comment
Hide comment
@AbstractBeliefs

AbstractBeliefs 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.

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

This comment has been minimized.

Show comment
Hide comment
@Baughn

Baughn 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.

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

This comment has been minimized.

Show comment
Hide comment
@ctrlcctrlv

ctrlcctrlv 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...

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

This comment has been minimized.

Show comment
Hide comment
@AbstractBeliefs

AbstractBeliefs 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".

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

This comment has been minimized.

Show comment
Hide comment
@Baughn

Baughn 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.

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

This comment has been minimized.

Show comment
Hide comment
@woodruffw

woodruffw 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.

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

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter 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.

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

This comment has been minimized.

Show comment
Hide comment
@rysiekpl

rysiekpl 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.

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

This comment has been minimized.

Show comment
Hide comment
@Matthew-Jemielity

Matthew-Jemielity 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?

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

This comment has been minimized.

Show comment
Hide comment
@annejan

annejan 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.

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

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jan 30, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jan 30, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 1, 2016

Member

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.

Member

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.