
Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' - dogecoinbase
https://github.com/systemd/systemd/issues/2402
======
Someone
The comments by Lennart Poettering, IMO, are a prime example of the schism
between what is needed for reaching "the year of Linux on the desktop" and
what some hackers think is best.

Nobody sells a chainsaw with safeties disabled, remarking "you can always
attach the chain catcher" if people report a couple of accidents, but Lennart
thinks requiring almost every user to change the default install ( _(note that
you can remount it readonly at boot, simply by adding an entry for it into
/etc/fstab, that is marked "ro"_) is a better idea than mounting it read-only,
and requiring those few who need to write these variables to do some extra
work by remounting it read-write.

~~~
kbenson
That is an extremely uncharitable reading of what he wrote, and I don't think
it captures the essence of his intent at all. He said:

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

It needs to be accessible in some manner.

> The ability to hose a system is certainly reason enought to make sure it's
> well protected and only writable to root.

Agreement it needs to be guarded, because it's a problem if it can hose a
system.

> But beyond that: root can do anything really.

This is a truism for Unix, and altering this is much more of a problem than
the occasional bricked machine. This is free software, and the ability to use
it to control our hardware to the fullest extent possible is part of that
freedom. Root cannot and should not be restricted from doing what it needs. It
_can_ , have hurdles put in place to make it harder to accidentally do
something it doesn't mean to do though.

So, agreement on the problem, and agreement that something needs to be done to
fix it, and a caution that access can't be entirely closed off without
consequences, so root needs access. What's so horrible about that?

~~~
deathanatos
Not only is root root, and should be permitted to access and modify the system
as desired, it seems to me that the root of this problem is that motherboard
manufacturers are shipping faulty boards. I shouldn't be able to brick my
motherboard from my operating system, and that I can _is_ a bug. You're
telling me there isn't so much as a factory reset on these boards?

Perhaps systemd _could_ shield users from their motherboard's manufacturer's
stupidity, but the amount of flack being received doesn't seem warranted; has
the same amount of outrage been directed towards the manufacturers?

~~~
clinta
We've been living in a world where you couldn't brick the firmware from the OS
for a long time, and it's been terrible. I'm perfectly happy to take the risk
of being able to brick a board from the OS if it means I never again have to
try boot to a dos disk and run a proprietary exe to update the BIOS.

Some boards do have something of a "factory reset" in the form of dual bios so
that if one is bricked, the backup can still be booted. But it's not a bug
that not every motherboard has this feature.

~~~
Sophira
The point isn't that it _can_ be bricked; it's that it's possible to brick it
via an "rm". Or heck, doing _anything_ hardware-related via an 'rm'.

The UNIX philosophy of "everything is a file" has always been based around the
conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if
you remove a device node (block or character-based), it doesn't care if you
remove a pipe, and it doesn't care if you remove a socket - even though all of
these things are interfaces to the kernel in one form or another. Removing
these files only removes your ability to access that interface.

Simiarly with files in /proc - which, like /sys, is directly exported by the
kernel. In many cases the kernel refuses to even allow you to unlink the
'files' in /proc, even when it might make sense. (For example, you can't kill
a process by 'rm'ing anything in the relevant /proc directory.) Instead, you
update the configuration values that the files in /proc represent by echoing
into their contents, where applicable.

The case with the efivars 'file' actually causing the kernel to take action
when it's removed is what's at issue here. The fact that it happens to brick
some computers is particularly unfortunate, but does a good job with showing
the problem here. This isn't what the "everything is a file" philosophy is
about.

~~~
clinta
I was not defending SystemD, I was defending the hardware manufacturers
against the accusation that they're "shipping faulty boards".

I think SystemD is in the wrong here. Operating Systems should be protecting
users from bricking their hardware.

Harware manufacturers should not be shipping hardware that's nearly impossible
to brick, because it results in hardware that is nearly impossible to update.

------
mmastrac
These threads are never productive. Running rm -rf / is going to offer
multiple interesting ways to make your life miserable, eg: a mounted FUSE
filesystem, an NFS folder pointed somewhere important, Samba mounts from your
network automatically connected from your desktop, etc. I wouldn't be
surprised if you could nuke firmware off a device by deleting the appropriate
file in /sys/.

Systemd hate is en vogue these days so they are an easy and common target. Why
no invective towards the kernel that actually implements EFI-as-a-filesystem?

~~~
mikeash
Sometimes people run rm -rf / just for fun before reformatting a system, just
to see what happens. Given that its purpose in life is to delete files, it
stands to reason that running this command on a system which contains no
important data is OK. A _default_ configuration which makes this command
_destroy hardware_ is not reasonable.

~~~
kbenson
rm -rf / probably doesn't do what you think it does. The coreutils version of
rm includes --preserve-root[1], which is the default[2].

It also supports --one-file-system, which would prevent this and a host of
other problems as well. That said, I don't really see a problem with Lennart's
response. It's basically, "we should take steps to make this hard to do, but
root is capable of doing anything, so don't expect it to be foolproof."

1:
[https://www.gnu.org/software/coreutils/manual/html_node/rm-i...](https://www.gnu.org/software/coreutils/manual/html_node/rm-
invocation.html)

2:
[https://www.gnu.org/software/coreutils/manual/html_node/Trea...](https://www.gnu.org/software/coreutils/manual/html_node/Treating-_002f-specially.html#Treating-_002f-specially)

~~~
mikeash
Is there some response besides the one linked here? Because all I see here is
basically saying, "We're not going to change anything, this is not a problem,
remount it yourself if you don't like it."

~~~
kbenson
He says "The ability to hose a system is certainly reason enought to make sure
it's well protected and only writable to root." That looks like agreement that
it needs something done to me. I took the followup comment to be a useful to
on how to mitigate the problem until then.

~~~
mikeash
Isn't it already only writeable by root? The request is to make it not even
writeable by root without taking some additional action to make it writeable
first. If I understand correctly, that bit you quote just describes the
current situation.

~~~
kbenson
I take the _and_ in his reply to infer he agrees something additional should
be done. Whether his ultimate response for _how_ to do that is adequate is
unknown, since he didn't really elaborate on exactly what he thinks should be
done. It could be he meant that to signify agreement with the suggested course
of action in addition to agreement that there's a problem to be fixed.

In any case, the only thing clear to me from his statements is that he agreed
that there was a problem in need of attention, which makes the response here
somewhat baffling to me (although not as baffling as it _should_ be. It's
fairly easy to see how a lot of the animosity comes from feeling about systemd
in general and Lennart in particular, especially since some people state as
much, as if that has any bearing on his response in this instance).

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

He's suggesting that not mounting it as read-only by default will break a few
things like grub-install, but promptly suggested editing /etc/fstab to mount
it read-only by default.

So... his own solution to the problem is to mount it as read-only.

The hard drive analogy is ridiculous because while you can lose data you
cannot brick your hard drive or computer by erasing it. There are ways to
brick a hard drive by corrupting the firmware but there are very specific
tools like "hdparm" that you have to use to do it, not an everyday command
like "rm".

This makes me wonder why Linux only has a single "root" user rather than
multiple types of administrators. Windows, for example, has Administrator,
which can do nearly everything, but some files and processes are protected
under SYSTEM or TrustedInstaller. If you REALLY want to, you can still remove
those files by changing ownership, or launching a command prompt with SYSTEM
permissions, but it does add a significant hurdle to doing things that could
cause significant damage.

~~~
rando3826
In linux, there is the immutable file attribute which won't let root rm the
file without first changing it with chattr.

~~~
ploxiln
File attributes need to be implemented by the filesystem. efivars is a pseudo-
filesystem which does not implement them. It could, but that is one of the
more needlessly complicated solutions...

------
ajross
To be fair, userspace access to these variables is required in order to manage
EFI boot. Having them there to be deleted (by root!) accidentally is probably
bad, but this isn't a meaningful security fix.

The real crisis here is that modern firmware is developed in an environment so
fragile and isolated that it's simply unable to recover from configuration
that is "wrong".

I had a laptop that I bricked about two years ago by accidentally wiping out
the partition table on the soldered-down storage.

~~~
mikeash
I don't think this is meant to be a _security_ fix, it's just meant to make it
so you can't accidentally break your hardware with what seems like an
unrelated filesystem command.

I agree that the stupid firmware is ultimately to blame, and mounting this
stuff read-write is a fairly reasonable initial decision. But given the
existence of this stupid firmware, the resistance to implementing an easy
mitigation by mounting it read-only is insane. I can't understand why there
are any responses besides "oh shit, we'd better change this."

~~~
snuxoll
Technically, denial of service is a security issue - I have modern servers
that boot via UEFI (since GPT is required to support large disks), hopefully
with less buggy implementations but if someone manages to get root on a server
they could totally kill the hardware.

Having to reinstall an OS because some script kiddie decided to `rm -rf --no-
preserve-root /` your server bites, but actually bricking the system requiring
a board replacement is scary. (Of course, they could technically be a jerk and
flash your UEFI EEPROM, but most servers have a backup they will restore from
in case the primary has been corrupted).

EDIT: Though, now that I think about it, this is still only going to stop
users from hosing their systems. A malicious user could still run an arbitrary
binary or kernel module that hoses the UEFI variables as well. Or by modifying
the UEFI boot config to load some other custom UEFI binary to hose it...
firmware vendors really just need to get their crap in gear, software (even
running in UEFI boot services mode shouldn't be able to hose it).

~~~
mikeash
Regarding your edit, exactly. The issue could be considered a security issue,
but this fix is not a security fix. A security fix would be something like
only allowing touching EFI during startup and then somehow securely and
permanently disabling that ability until the next reboot, or a physical write-
protect switch on the computer.

Or EFI firmware not being so stupid, but we know that's not going to happen.

~~~
snuxoll
Maybe if there was some awful Windows virus that nuked boards with bad
implementations they would fix their crap.

~~~
yrro
Bingo. You're only a call to SetFirmwareEnvironmentVariable away from having
your Windows system hosed.

------
bsder
This isn't a systemd problem. It's a kernel problem.

Allowing accidental access to a resource capable of doing permanent damage is
dumb. Even embedded processors generally have an "unlock/lock" sequence when
you want to write to their flash memory.

The fact that the kernel doesn't require you to write a "magic number"
somewhere to gain access is foolhardy.

------
andmarios
One day I broke my laptop's boot list, so I went to add a new efi boot entry.
I couldn't and thought it was due to my inability to find a proper usb
bootable media with efi support since you can't access efi-vars if you boot
from bios.

Turns out linux used to store crash-dumps inside efi-vars, so mine were full
and new entries couldn't be written. Good thing /sys/firmware/efi/vars/ was
mounted rw, thus a `rm -rf /sys/firmware/efi/vars/dump-*` fixed it.

Some kind of protection would be nice, but the ability to see and use efi-vars
as a filesystem is useful too. If we listen to security researchers too much,
our computers will be no fun.

~~~
milkey_mouse
Breaking your laptop's boot list _will happen more often_ with it mounted RW
anyway. So it's good it fixed it for you, but I doubt the number of cases it's
fixed something/been useful outnumbers the cases where someone bricks their
system using what is probably the most repeated Linux command on the internet:
rm -rf /.

~~~
andmarios
The reason the efi's boot list was broken was because I wanted to replace a
HDD. The laptop has 2 HDDs, I removed them and booted with the new, empty disk
for an experiment before adding back my system disk. UEFI thought is was
appropriate to remove the non-existing disks' entries from its list and thus I
couldn't boot anymore.

Anyway, I don't think this is a systemd bug. The /sys interface comes from the
kernel and whether you will access efi vars depends on your kernel
configuration. There is the older module (I believe _efivars_ if it isn't
compiled as built-in) and the newer (I believe _efivarsfs_).

I've done my fair share of systemd bashing but here we have:

    
    
      1. Broken and/or naive EFI implementations
      2. Linux kernel's default choices (expose efivars as rw)
      3. Distro's choices (compile kernel with said modules as built-in)
    

And we give the fault to systemd. Every other init system out there does the
same.

------
endgame
And that's the sort of thing that could easily sneak into the `curl
[http://some/url](http://some/url) | sudo bash`-style of installs that are
popular these days.

~~~
moonbug
Good.

~~~
snuxoll
I could do it in an RPM post-install script too if it will get people to stop
whining about running arbitrary scripts.

All software you install on your system through binaries is potentially
suspect to an extend. Sure, I trust the Fedora build system to do the right
thing, so I can with some certainty assume anything in the Fedora Collection
or EPEL is "safe" \- but when I need to install 3rd party software to get my
video card working I can throw all that out the window.

Be sane when testing _any_ binary you install, at least with RPM's or DEB's I
can verify the GPG key of the vendor - assuming they bother to use one at
all... piping scripts directly from curl to bash is bad because of the
potential of the stream ending early and leaving in an inconsistent state,
that's the only thing that is notable worse versus installing a package (and
can be worked around by downloading it first, THEN executing it).

~~~
chris_wot
Given you need to be root to install software on an Ubuntu system, a deb could
do that also.

------
Sanddancer
Unless you're doing something super screwy, GRUB, the excuse for this
backwards default, doesn't even need access to UEFI. UEFI booting looks for a
file in a FAT-formatted partition of a hard disk with a specific ID --
C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT disks and 0xEF for MBR disks. All
EFI does is to look for a file BOOTX64.EFI on that partition. There's no need
to muck around the UEFI settings for this, it Just Fucking Works.

~~~
JoshTriplett
Only removable disks use bootx64.efi, though some (but not all) BIOSes will
look for that on fixed disks too. efibootmgr needs access to efivarsfs to
configure an EFI boot entry for Linux on a fixed disk. Relying exclusively on
bootx64.efi on the EFI system partition will break on some devices, and will
overwrite the Windows bootloader (and conversely, Windows doing so will render
Linux unbootable).

~~~
Sanddancer
The standard is for EFI to look for that partition on all disks, even hard
disks. If there are a few broken systems that do otherwise, they could use
other methods, but keeping things mostly standardized seems like the best way
to go. It's how Windows does it, it's how FreeBSD does it, it's how OpenBSD
does it, etc. Mucking around with it doing otherwise is just asking for
problems.

~~~
JoshTriplett
The EFI standard specifically limits that to removable media. Windows installs
itself via the EFI boot variable mechanism; Windows _also_ installs itself to
bootx64.efi, but even if you overwrite that, you can still boot Windows via
its EFI boot entry. Having Linux systems install themselves only to
bootx64.efi would produce a fragile installation (particularly in dual-boot
configurations).

~~~
Sanddancer
Okay, I read the standard and you're right, they are supposed to install to a
vendor specific location, so my apologies. Boot's an additional place you can
put it, but not the regular place.

As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you
want to boot as bootable, and away you go. here you have to copy the
bootloader file, and then write to the firmware what file you want to boot,
which feels even more fragile and confusing if you decide to wipe a hard drive
to put a new OS on it unless you do everything just right.

~~~
simoncion
> As an aside, goddamn is UEFI ugly.

You're goddamn right it is. Matthew Garrett [0] used to do UEFI stuff for
-IIRC- RedHat. He has MANY blog posts about fucked-up parts of the spec, and
horrifyingly fucked-up implementations of the same. Sadly, it looks like most
(if not all) of his posts are now tagged "advogato, fedora", so I can't point
you specifically to the UEFI gore posts.

[0] [http://mjg59.dreamwidth.org/](http://mjg59.dreamwidth.org/)

~~~
yuhong
My personal favorite is how
[http://lkml.org/lkml/2013/11/11/653](http://lkml.org/lkml/2013/11/11/653) is
posted by @hp.com that also locked access to UEFI updates to paid customers
not long after it was posted.

------
JulianMorrison
Why not just turn off recognition of "rm" in the efivarfs? That is, the
response to "unlink" of a file that represents a system abstraction of
firmware should be something drastic only to the unlinker. SIGSEGV or
something. "Go away, don't do that."

~~~
eeZi
Well there are use cases where you'd _want_ to remove an EFI variable.

~~~
cnvogel
Then just require the efivars to have different semantics, just have a look
like unbind works for drivers. If you really want to be super cautious, add a
safeguard to enable this.

    
    
        echo 1       >/sys/...efi.../enable_remove
        echo varname >/sys/...efi.../remove_var

------
CoconutPilot
Unix has a long tradition of doing a `rm -rf /` before reinstalling a system.
I don't agree with the people saying "don't do that". It worked safely before,
it should still be safe to do.

(yes I know about --no-preserve-root)

~~~
magila
`rm -rf /` was never safe, even if reinstalling the system. If it worked for
you then you were just lucky. In the context doing a reinstall you need to
specify --one-file-system, but really you should just reformat the partition,
it'll likely be much faster anyways.

~~~
krylon
On one episode of BSD Now[1], Bryan Cantrill tells how they made 'rm -rf /'
not work on Solaris. It seems like a good idea in that they managed to stay
compliant to POSIX while disarming that particular foot seeking-missile.

Or, in other words: I agree completely, in fifteen years I have never used 'rm
-rf /', I always used mkfs to create fresh filesystem.

[1]
[http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_k...](http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_kittens)

------
chris_wot
That's a dreadful response from Pottering.

------
Aloha
So, the short read here is, one (arguably poorly thought out) complex system
interacts with another (again, arguably poorly thought out) complex system in
unthought about ways... Why is anyone surprised?

I'm no fan of systemd or Poettering, but this behavior is consistent for unix,
root can do anything, including break peripherals or hardware thru poorly
advised actions - why is this a big to do?

~~~
bigbugbag
Because this is a violation of principle of least astonishment[1], as a
sysadmin when I hose my system using rm I expect to be able to repair or
recover without having to replace the motherboard.

see also:
[https://bbs.archlinux.org/viewtopic.php?id=207549](https://bbs.archlinux.org/viewtopic.php?id=207549)
[https://bbs.archlinux.org/viewtopic.php?id=208102](https://bbs.archlinux.org/viewtopic.php?id=208102)

[1]:
[https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)

------
alexandrerond
How long before someone realises that grub could also be made part of
systemd... _cringes_

~~~
simoncion
> How long before someone realises that grub could also be made part of
> systemd...

[https://wiki.archlinux.org/index.php/Systemd-
boot](https://wiki.archlinux.org/index.php/Systemd-boot)

~~~
alexandrerond
This is why I didn't even want to google it... ignorance is bliss. Thank you,
i guess...

------
sjukfan
I can't understand why people argue about this. Just put some safety measures
on it already. Or at least change the rm option to "\--brick-my-motherboard"

~~~
rcxdude
Honestly, I feel the issue is more rm -rf's default behaviour being to cross
filesystems. This is almost always not what you want (and tends to result in
deleting network drives, to give an example which has nothing to do with
systemd), especially considering attempting to delete a mount point fails.

~~~
mikeash
I think there are at least three issues here.

One is efivarfs making it too easy to destroy stuff. It should probably
identify problematic hardware and prohibit modifications that break that
hardware. This is no fun, but hardware-specific workarounds are a fact of life
for real-world OSes.

One is, as you say, bad default behavior with rm. Crossing filesystems by
default is pretty weird. Preventing that unless it's explicitly requested
would largely fix this problem and many others too.

And one is mounting efivarfs read-write by default. It's too dangerous to be
that easy to modify.

I don't think it's too useful to try to pin one of these down as "the issue."
They're all worth fixing.

------
cmurf
Could be a job for SELinux. Most of the files in efivars don't ever need
modifying. So SELinux could make all files unmodifiable by default, and allow
modification of the few that are needed by efibootmgr.

~~~
snuxoll
Unless you set SELinux to run in strict mode root still has access to delete
everything.

------
JdeBP
See also
[https://news.ycombinator.com/item?id=11008449](https://news.ycombinator.com/item?id=11008449)
.

------
jasonmoo
sensible defaults

