
No POST after rm -rf / - wsx
https://bbs.archlinux.org/viewtopic.php?id=207549
======
Cartwright2
Reading poettering's response
([https://github.com/systemd/systemd/issues/2402](https://github.com/systemd/systemd/issues/2402))
I'm left feeling like he needs a thorough "Mauro, SHUT THE F __* UP " response
from Linus himself
([https://lkml.org/lkml/2012/12/23/75](https://lkml.org/lkml/2012/12/23/75))

~~~
zanny
It is _not_ a systemd bug to mount efivars read/write. The efitools -
efibootmgr et al - _require_ write access to that table. By the spec, this
should not brick computers.

The problem is not systemd, its disastrous proprietary UEFI implementations
that are shipping the most insecure and awful code in the world.

The _problem_ is we _cannot_ fix this for 9233. MSI will absolutely refuse to
disclose the firmware to his laptop so that he can make it so his replacement
does not also brick itself. People have been treating coreboot / libreboot
like a joke for a decade, but this is exactly why those projects matter and
why the continued erosion and trend towards firmware blobs and proprietary
bootloaders cripples individuals control of the hardware they supposedly own.

Its the John Deere tractor problem, but until enough people care - I mean,
enthusiasts and techies already don't care, and we would need a popular
general consumer movement to care to inspire real change - it will only get
worse.

All the 802.11 AC wireless NICs in the Linux kernel use firmware blobs. As of
Skylake, there is not a single GPU supported on x86 systems in Linux that does
not use firmware blobs. Almost every Chromebook is shipping Coreboot with
cancerous unauditable firmware blobs. Samsung SSDs have bricked themselves
because of their proprietary firmware blobs. Its a constant endemic problem
yet nobody cares to put their money where their mouth is.

~~~
ploxiln
Yes, firmware blobs suck, no argument there. But forget about that aspect for
a moment, and consider the firmware a mostly unchangeable part of the
hardware.

Hardware has bugs. A lot of hardware has had bugs for a long time. Linux has
had tables of "quirks" for hardware pci ids / usb ids / etc. for a long time,
for thousands of buggy hardware devices it needs work-arounds for. Some of
those bugs are really in hardware, some are in the firmware loaded on the
hardware, it doesn't really matter. This is a pervasive reality, and it can't
just be demanded that the user get hardware which is not "shitty" by this
metric ... it's all a trade-off.

And finally, I've used linux on bios systems and efi systems, and I've never
needed efivars mounted, I've always set up the bootloader some other way
(which was simpler for me to control and manage as I prefer). My personal
biggest complaint about systemd is how it automatically mounts and starts and
uses all kinds of stuff that I don't need. I prefer to set up what I need and
want, and not have anything else cluttering up my system, just waiting to
cause serious reliability or security problems, and getting in my way when I'm
debugging something else.

So I'll be up-voting all stories about "systemd did something automatically
and on some systems it was unfortunate" because yeah, UNFORTUNATE STUFF
HAPPENS WHEN STUFF HAPPENS AUTOMATICALLY. This is why I left windows and OS X
in the first place! So I had easy and convenient control over my computer! And
now it takes extra effort to override and disable all the crap that systemd is
doing automatically, and I resent it. (I actually already have a script on my
systems that unmounts efivars and pstore and some other unneeded filesystems
after boot.)

~~~
belorn
The road to compile your own kernel and build your own distribution is well
documented and there is even several books on the topic. Compiling your own
system from scratch without the aid of a distribution makes it easier to
appreciate the automatic defaults that usually gets installed.

I personally do not want to be forced to know all the hazardously settings
that exist in the kernel and base system. I want sane defaults, defaults that
are set automatically when I install my Debian packages. If I disagree with an
automatic default, my options are to either utilize the control (freedoms)
that FOSS software provides, or issue a bug report and try get the community
to agree with my views.

If "rm -rf /" is a valid use case/concern, send up a bug report. Its better
than trying to remove automatic defaults from distributions.

~~~
detaro
And you think in this case allowing the user to brick the system is the sane
default, instead of putting it hinter an (easy to flick) switch?

~~~
jerven
It is behind and easy to flick switch called: su or sudo. The claim is that
systemd should add a second switch because the first one is "not enough" that
the systemd devs disagree with.

There are more operations that root can do that can brick a system or destroy
hardware. Why should systemd try even harder to make root not do that?

~~~
detaro
Because working with su/sudo is still something that's often enough required
for normal operations, that IMHO shouldn't have side-effects of that level.
The "with great power..." spiel sudo displays is nice, but it isn't just
experienced sysadmins running sudo anymore.

Since the OS doesn't provide permission levels to express this difference, it
makes sense to create that isolation otherwise.

I've run rm -rf as root in the wrong directory before, and nuked stuff that
required a backup to fix. I'd prefer if everything worse than that required
some extra mental confirmation that, yes, I'm sure I want to do that.

~~~
belorn
There is always SELinux which can limit root. It was fairly easy to setup last
time I tested it, and there has been attempts in the past to put it in as
default.

A lot of distros also alias "rm" to "rm -i", something that many users
explicitly disable. Its a complex problem of security vs usability where most
discussions has been rehashed several times.

~~~
digi_owl
Personally i find rm too accepting, and rm -i too restrictive.

Using rm on its own will happily perform the command without further
verification.

On the other hand, rm -i will request a yes/no on every last file involved.

Personally i have taken to using mc for any "complex" file system
manipulations.

------
userbinator
Things like this add to my impression that UEFI is a solution looking for a
problem. The fragility caused by all this extra complexity is extremely
undesirable for a system component whose only job should be to test and setup
the hardware minimally, then leave the rest to the OS.

Then again, there's also the question of why removing EFI configuration
variables would make the machine unbootable; you would think that in the
absence of any explicit configuration, the firmware should just choose a sane
default. That would be like making an rm -rf / also reset your BIOS settings,
which is probably surprising but easily recoverable behaviour. This seem as
crazy as mounting the whole flash ROM as a filesystem, so deleting it erases
the firmware. The symptoms described do sound like what happens if you try to
boot a motherboard with a completely blank BIOS chip (from personal
experience...) --- the system will power on and just stay on, but nothing else
will happen, not even a POST beep.

Edit: given that the majority of users have probably never touched BIOS/UEFI
settings so that they remain at defaults, resetting them would not be noticed
by them either. It's likely the advanced users, the overclockers and so forth,
which will be running non-defaults.

~~~
zanny
It took Linksys months to make their firmware for their "new open source" WRT
routers reasonable enough that DDWRT / OpenWRT didn't have to deny their
patches.

All these hardware companies - the motherboard makers, the wifi radio makers,
the hard drive makers, the peripheral and chipset makers - all write the most
awful insecure disastrous code in the industry. But because nobody cares
enough to put their wallet where their mouth is and refuse to buy hardware
without access to the firmware to audit, improve, fix, or replace it this is
what you are left with, and you get what you pay for.

And there are plenty of firmware settings you might want to change even
without overclocking. Change the default boot hardrive? Firmware. Turn off
unused ports on your motherboard? Firmware. Change fan speed settings?
Firmware. Any implementation of network / usb booting? Firmware. Full HD
encryption? Firmware.

I just know the next laptop I buy will be whatever the highest end liberated
Chromebook at the time is, preferably without cancerous firmware blobs that
control everything, but that seems unlikely considering how anti-freedom Intel
is.

I just hope AMD saves x86 computing in the Zen generation. They are the
underdog, they have reasons to not throw users under the bus for complete
control of the platform like Intel does. But their hijacking of radeonHD and
injection of firmware blobs there doesn't make me hopeful for first-gen
freedom respecting hardware from them any time soon either.

RISC-V, save us!

~~~
wsx
> I just know the next laptop I buy will be whatever the highest end liberated
> Chromebook at the time is, preferably without cancerous firmware blobs that
> control everything, but that seems unlikely considering how anti-freedom
> Intel is.

Yep, I don't think you'll find x86 Chromebooks without blobs. Nowadays the
only way Intel provides to boot their hardware is "here, take this binary and
put it at the beginning of your BIOS".

Same thing with AMD, btw.

~~~
zanny
I'm fine with ARM, hopefully future iterations of the ASUS C201[1] are
portable to Libreboot in the future by the time I'm shopping for a new laptop.
It won't be for a while, I hate giving these scum freedom denying companies my
money for locked down puke.

[1]:
[https://libreboot.org/docs/hcl/c201.html](https://libreboot.org/docs/hcl/c201.html)

------
myztic
Reminds me of Cantrill, more so his story when they completely bricked a
machine of a fellow worker once and then took a close look at the standard[1].

# rm -rf /

Among other things, it will delete the current directory. In the standard it
does not say what to delete first, In their implementation it will try to
remove the current directory first -> undefined behaviour -> it fails.

The logic behind it: When is it really your goal to delete your entire
machine, mostly never, you don't type it out by accident, but shell scripts
with unset variables might do it.

And regarding Poettering's response[2] (not trying to start a fight): It's
Poettering, what do you expect? You can hate or love systemd, but part of why
people hate it is his intellectual arrogance in everything he does.

[1] He tells the story somewhere in here
[https://www.youtube.com/watch?v=l6XQUciI-
Sc](https://www.youtube.com/watch?v=l6XQUciI-Sc) (quite entertaining)

[2]
[https://github.com/systemd/systemd/issues/2402](https://github.com/systemd/systemd/issues/2402)

~~~
toast0
> And regarding Poettering's response[2] (not trying to start a fight): It's
> Poettering, what do you expect? You can hate or love systemd, but part of
> why people hate it is his intellectual arrogance in everything he does.

I don't think it's just his arrogance, it's that it's not backed up by
substance. Linus is an arrogant prick, yeah? But his kernel works pretty well,
so he gets some slack. All pulseaudio ever did for me was waste my time and
break my ability to output sound. Systemd wastes my time, makes my computer
work different for no reason that's apparent to me, and now makes it easy for
me to brick my machine if I'm not careful and I have a terrible bios[1].

[1] I've yet to meet a bios that isn't terrible, although hopefully few are
terrible in this specific way.

~~~
aidenn0
I disagree with Poettering's technical decisions more often than I agree with
them, but to be fair, some of PA is because the distros adopted it early.
Heck, when Ubunutu picked it up the readme still described it as something
along the lines of "The server that breaks your audio system."

------
DblPlusUngood
It is both terrifying and amusing that rm'ing files in /sys can brick my Linux
machine.

I find it even more worrisome that some compare this mistake to accidental
clobbering of /dev/sd?.

~~~
NamTaf
Lesson learned: if you want to semi-permanently take a system offline, hope
they have a bad EFI implementation and rm -rf /sys. The fact that a malicious
actor can compromise your hardware via software like that is incredible.

That's an insane design decision and if I replicated that in my professional
capacity designing heavy machinery I'd be rightly fired and sued to oblivion
because the equivalent result is dead people. This is a basic case of the
principle of safety-in-design.

~~~
zanny
Which is why the campaign for liberated firmware is so important. If
motherboard manufacturers were committing work to a common project like
libreboot then hundreds of eyes would be upon it and awful code that does this
insanity would never enter official repos.

Linksys had this problem a few years back with their new line of "open source"
routers - it took them months to clean up their awful internal coding styles
to get patches accepted into DDWRT, and even then they were accepted on a
compromise where DDWRT developers had to fix a lot of it to make it less of a
security portability and readability nightmare.

These hardware vendors at all levels - storage controllers, chipsets, radios,
and more all have absolutely no QA on their code and by being so extremely
proprietary nobody can do anything about it, and not enough people care to
speak with their wallet to changes these terrible habits.

~~~
rimantas

      > then hundreds of eyes would be upon it and awful code that
      > does this insanity would never enter official repos.
    

As the example of OpenSSH clearly shows.

~~~
wsx
Well, the insanity would _rarely_ enter official releases.

There is no comparison between the bugginess of BIOSes and OpenSSH.

------
JdeBP
Here are some interesting items to think about.

Here's OpenRC _also_ mounting this filesystem read-write, since 2013:

* [https://github.com/OpenRC/openrc/blob/e52b5f59c22283b22e2b5a...](https://github.com/OpenRC/openrc/blob/e52b5f59c22283b22e2b5a0d2ab9de6b92a73ebf/init.d/sysfs.in#L99)

* [https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169e...](https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169eaa465ef90349d1ee367e)

Here's a Debian bug from a year and a half later, asking for systemd to do the
same on Debian Linux:

* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773533](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773533)

And here's Finnbarr P. Murphy in 2012 explaining the whitelisting that the old
efivars system imposed upon variable access, stating that this system "should
be retired", and questioning why these checks are not performed in
applications-mode code rather than in kernel-mode code. I suspect that a lot
of people can now answer that question, with hindsight. (-:

* [http://blog.fpmurphy.com/2012/12/efivars-and-efivarfs.html](http://blog.fpmurphy.com/2012/12/efivars-and-efivarfs.html)

~~~
digi_owl
One thing of note is that OpenRC is done via shell script, so going in and
adding a ro option should be straight forward.

With systemd it is done in the C code of their init binary, thus you have to
work around it by a remount on fstab.

------
detaro
dupe: the matching systemd bug
([https://github.com/systemd/systemd/issues/2402](https://github.com/systemd/systemd/issues/2402))
has been extensively discussed yesterday
[https://news.ycombinator.com/item?id=10999335](https://news.ycombinator.com/item?id=10999335)

------
phantom_oracle
Wasn't the fear of such bloat developing on Linux one of the main reasons why
so many/few people were against systemd?

Many regular (and somewhat tech-minded) individuals may not fully understand
the issue, but this issue was a problem that crept up due to pure coincidence
that somebody tried to _rm -rf_ something, otherwise that _bug_ would linger
like how OpenSSL bugs did.

I also really wish the pro-systemd crowd would stop attacking anybody that
does not agree with their views. Linux was and always will be about community,
and if you alienate the rest of the users, freedom means they will (and
probably should) move on, even if 90+% of Linux-variants now use systemd.

~~~
otterley
This issue doesn't really have anything to do with the scope of systemd and
its sidecar utilities (unless you're concerned that it mounts
/sys/firmware/efi/efivars/). It's just a debate about what the default mount
options should be.

------
protomyth
I am still left with the same thought as yesterday's article, why was the
decision made to mount efi as a filesystem in the first place? It's obviously
dangerous to mount it when there are unintentional interactions that can have
extreme effects. A library approach such as how FreeBSD does is much safer.

------
wsx
tl;dr: This can permanently brick some/many/all? UEFI devices. Three cases
confirmed so far on Lenovo/MSI/unknown hardware.

Linux distribution other than Arch are likely to be affected as well because
systemd is hardcoded to mount the EFI variables pseudo-filesystem with RW
access on every boot.

------
cyphar
Matthew Garret proposed a solution to this problem, disable writes to all non-
standard UEFI variables until we can sort out the bugs:
[https://twitter.com/mjg59/status/694004077923938304?s=09](https://twitter.com/mjg59/status/694004077923938304?s=09)

------
finid
From the comments on that forum, seems like a lot has changed since
[http://linuxbsdos.com/2012/04/29/what-will-rm-rf-actually-
do...](http://linuxbsdos.com/2012/04/29/what-will-rm-rf-actually-do-to-your-
linuxbsd-machine) was published.

------
bipin_nag
What I got from the thread: efivars are NVRAM registers for UEFI and are
mounted on /sys/firmware/efi/efivars and doing rm -rf clears/deletes them. And
they are required for booting.

Is this correct ?

~~~
MertsA
Yes and no, UEFI will look at those vars when determining how to boot the
computer but clearing them shouldn't brick the computer.

Basically the UEFI spec is crap to begin with and there are implementations
that make egregious mistakes that don't matter if the guest OS is Windows but
goes horribly sideways if something atypical comes up.

For instance, a while back there was a case of Linux bricking a bunch of
laptops because while efivars had space available, trying to use some of this
"free" space would leave you with a paper weight.

[https://mjg59.dreamwidth.org/22855.html](https://mjg59.dreamwidth.org/22855.html)

------
peterwwillis
Problem:

Systemd decides of its own accord (that is, the distro cannot tell systemd
_not_ to do this) to mount dangerous filesystem read-write by default.

"Solutions" provided by systemd developers:

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

We make sda writeable, yes. But it's much more difficult & unlikely one would
write a script that opens and overwrites random block files to destroy hard
drive data than it is one could untintentionally unlink random files, in this
case resulting in the destruction of hardware.

-
    
    
      "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 of, say, a bug in gummiboot or refind."
    

So since other software can also brick the hardware, systemd's behhavior does
not need to be fixed. Got it.

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

So because someone could _intentionally_ brick some hardware by being
malicious, it's pointless to prevent someone from _accidentally_ bricking
their hardware. Got it.

-
    
    
      "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."
    
      "If anyone needs protection from idiocy, mount it as ro in /etc/fstab."
    

So by default, every distribution in the world - and a bootloader - needs a
workaround for your software's dangerous behavior. Got it.

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

One of the commenters (devs?) mentioned that systemd could mount it read-
write, apply this change, and mount it read-only again, which would work
around the danger we've been talking about. But from this final comment it
seems like you (poettering) basically don't care about the problem.

Got it.

------
libeclipse
A lot of people are missing the point here. Of course it's not system's fault
here, but it's completely absurt for them to completely dismiss a fix just
because they're not at fault. efibootmgr requires rw access, but it is a root
process, so it could mount, do whatever it needs, and unmount again. It's a
much cleaner solution than making users edit their fstab to make it automount
as ro after install. That's just an ugly hack.

------
im2w1l
> some desktop motherboard allow to reinstall a corrupted firmware by putting
> a special named file on a usb key

This sounds fun and dangerous.

~~~
wsx
Probably not in this case, because affected systems don't give even a
slightest sign of life.

------
mkj
"Eventually he ended up sending the machine to MSI for repair, which will be
covered by warranty." explains most of it - broken hardware should be fixed by
the manufacturer.

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

------
wfunction
These sorts of problems wouldn't exist if *nix didn't think everything is a
file...

~~~
quasarj
True. It also wouldn't exist if people didn't rm -rf /.

There are good things that come from treating everything as a file.

~~~
__david__
True, and I generally like how I can poke around /sys with just ls and cat,
but perhaps somewhat sensitive boot configurations should live behind an ioctl
interface (or some other syscall) instead of being shoehorned into the
filesystem.

~~~
cyphar
ioctls are definitely the wrong interface (they require an open file, for
one). To be honest, there are very good reasons why the "everything is a file"
model is very useful. You can use it to do many more cool things with shell
scripts (such as changing the fan speed, or backlight brightness or any other
dodgy cowboy stuff). And at the end of the day, why is the "everything is a
file" model bad?

~~~
wfunction
> And at the end of the day, why is the "everything is a file" model bad?

Because not everything _is_ a file? And therefore forcing people to treat
everything as a "file", which they have certain natural expectations for,
leads to problems such as the one here when the objects cannot fulfill the
users' expectations?

> You can use it to do many more cool things with shell scripts (such as [...]
> dodgy cowboy stuff)

I feel this is fairly obvious... if your argument for the everything-is-a-file
model is a love for dodgy cowboy hackery, then is it really that surprising
that you're sacrificing something (in this case, usability/sensibility/etc.)
in the process? I mean, yeah, those who feel like cowboys might find your
system intuitive, but do you not see how it might not be very usable by (or
useful to) other people?

~~~
cyphar
> > And at the end of the day, why is the "everything is a file" model bad?

> Because not everything is a file? And therefore forcing people to treat
> everything as a "file", which they have certain natural expectations for,
> leads to problems such as the one here when the objects cannot fulfill the
> users' expectations?

"Everything is file" doesn't mean that everything is associated with a block
on disk. Filesystems are a very good (and intuitive) way of describing
hierarchies, and benefit from requiring literally only one syscall interface
that works will all of your tools and programming languages without needing to
update the stdlib. How would you propose to represent hierarchies using
syscalls? Would you have a "set_uefi_variable" syscall? How would that not
become unweidly? ioctls wouldn't work (not just because they're ioctls but
also because you'd need to open a file, and devices aren't files either --
because "everything is a file" is bad, right?). You could try doing it all
with kdbus (or something), and that might even be somewhat plausible. Until
you realize there's no way of doing anything that doesn't require breaking out
a C compiler. Shell scripts couldn't do simple things like change the dimness
of your backlight.

> > You can use it to do many more cool things with shell scripts (such as
> [...] dodgy cowboy stuff)

> I feel this is fairly obvious... if your argument for the everything-is-a-
> file model is a love for dodgy cowboy hackery, then is it really that
> surprising that you're sacrificing something (in this case,
> usability/sensibility/etc.) in the process?

It also doesn't require 500 pages of API docs each time you want to change
your backlight with a shell script. The whole point of Unix is to solve
problems quickly, not to have to break out your C compiler each time you want
to do something less trivial than renaming a file.

> I mean, yeah, those who feel like cowboys might find your system intuitive,
> but do you not see how it might not be very usable by (or useful to) other
> people?

Filesystems are intuitive to almost all users. When teaching Unix to my
friends, I start by saying "everything is a file" and move on from there. Why?
Because it's actually a useful abstraction. Filesystems are already incredibly
intuitive. Not to mention that nobody was actually complaining about how
intuitive it is to have efivarfs, it's a non-issue.

------
Qantourisc
My take on this is simple: is it a bug: no. Should we add more protections/add
quirk handling: yes, assuming we don't like people having a bad day over this.

------
necessity
As a BIOS and OpenRC user I always chuckle at this kind of news.

~~~
mwfunk
As a human being, I don't chuckle at other people's pain, nor do I brag about
it.

~~~
simoncion
> As a human being, I don't chuckle at other people's pain, nor do I brag
> about it.

I guess Germans aren't human beings? [0] :/

[0]
[https://en.wikipedia.org/wiki/Schadenfreude](https://en.wikipedia.org/wiki/Schadenfreude)

~~~
simoncion
To the downvoters:

mwfunk is making the _incredibly_ exclusionary statement that human beings
should not (and that he _does_ not) take pleasure in the pain and/or
misfortune of others.

We can infer from this things like:

* mwfunk does not chuckle when a series of unfortunate and _highly_ improbable events results in someone suffering very minor injury.

* mwfunk enjoys almost _no_ comedy, because the _vast_ majority of humor revolves around the retelling of stories where at least one of the participants has been harmed in some way, however minor.

* mwfunk does not feel any form of pleasure when a Bad Guy has gotten his comeuppance and is now being punished for the wrongs he inflicted on others.

It seems _rather_ unlikely that these three points (and the hundreds more like
them that could be inferred) _all_ apply to mwfunk. The more likely
explanation is that mwfunk is speaking from a _rather_ high horse, and hopes
that we groundlings can't hear when he chuckles at a _rather_ good joke in a
stand-up skit.

