9 ms·

No POST after rm -rf /

422 points by wsx 11y ago

finid 11y ago
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-to-your-linuxbsd-machine http://linuxbsdos.com/2012/04/29/what-will-rm-rf-actually-do... was published.
wsx 11y ago
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.
detaro 11y ago
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
necessity 11y ago
As a BIOS and OpenRC user I always chuckle at this kind of news.
- wsx 11y ago
  It's very funny until they drop BIOS compatibility mode from new machines.
  - wtallis 11y ago
    As long as they still let you turn off Secure Boot, I don't see why you can't just put a BIOS CSM in your EFI system partition and load it before proceeding with business as usual.
- mwfunk 11y ago
  As a human being, I don't chuckle at other people's pain, nor do I brag about it.
  - simoncion 11y ago
    > 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 11y ago
      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.
  - xyzzy4 11y ago
    You don't like the movie Dumb and Dumber?
  - deleted 11y ago
    [deleted]
- JdeBP 11y ago
  As (presumably) an ACPI user, you should rather be sympathizing.
- deleted 11y ago
  [deleted]
userbinator 11y ago
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.
- bittermang 11y ago
  The problem is the Linux based boot loader that circumvents Windows Activation Technology. I am convinced that -- and that alone -- is why we live with UEFI.
  - jgord 11y ago
    au contraire, the problem is windows thinks it owns the machine I bought for the sole purpose of running linux.
    - knowaveragejoe 11y ago
      It's poorly phrased, but I think he is agreeing with you.
    - deleted 11y ago
      [deleted]
  - 11y ago
DblPlusUngood 11y ago
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 11y ago
  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.
  - yrro 11y ago
    You can do exactly the same thing on Windows by calling SetFirmwareEnvironmentVariable. The problem is on the firmware side!
    - NamTaf 11y ago
      Yeh I wasn't laying blame on the *nix side of things either. No OS should be able to do this because the OS shouldn't have that level of control over the system it's sittting upon. Firmware absolutely shouldn't fail to a broken state. If you hose some configuration and it crashes, it should revert back to a known good configuration e.g.: a factory reset / fail-safe configuration. You shouldn't be able to hose it completely except through special equipment, for example by connecting to system programming terminals on the motherboard with external hardware. The fact that a higher-level system can damage a lower-level system is just bad design.
      - dh997 11y ago
        Dangerous tasks should have the most safety interlocks, but not require manual, needy attention that makes it harder to automate deployments. This edge-case functionality may still be useful for self-destructing / remote bricking sensitive embedded devices. efidestructivecmd opts... --really-brick-myself-and-catch-fire # fire optional
im2w1l 11y ago
> 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 11y ago
  Probably not in this case, because affected systems don't give even a slightest sign of life.
Cartwright2 11y ago
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)
- nextos 11y ago
  He needs one, and you shouldn't get downvoted for saying this. Systemd has brought lots of good things to Linux, but tons of bloat and insanity too. I'm quite scared because the next thing they seem to be tackling is one of the core things that makes Linux so nice, package management [1]. They intend to container-ize everything. While that might be in principle good (NixOS got it right), their solution is likely to end up being a mess: no control over container contents. Imagine a critical security bug on e.g. OpenSSL. Good luck patching all your dozens of unmanaged containers running different OpenSSL library instances. [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...
  - dh997 11y ago
    Reinvention without purpose often appears to take credit for fixing "old==bad" and dodging blame for churn, usually ortogonal of understanding of users' needs: enterprise, industrial embedded, IoT, desktop, mobile, etc. and the actual pain and cost of change at large scale (beyond people one knows and non developers).
  - derefr 11y ago
    From my perspective, containers just make explicit what's always been true: the library dependencies linked into the "release" of an "app" need to be stewarded by the app developers, rather than the OS distributor. System components are owned by the system maintainer, but apps are owned by their developers, and the SLAs are separate. If Nginx, for example, has a security flaw, it's properly Nginx's job to make a new container. That flaw might be because of Nginx's dependency on OpenSSL, but it might also be because of a vulnerability in Nginx itself. Nginx (and every other "app" developer) needs the process in place to get new releases out in the latter case; if they have that process, there's no reason to not apply it also to the former case. Distro maintainers have been picking up the slack of creating "security releases" for app software for decades now, but they only do it because app developers were unwilling to take on the responsibility of maintaining packages in several different package ecosystems. App developers are not nearly as timid when it comes to container-image releases, since it's just the one QA process rather than five. So, properly, the responsibility—and the SLA—is reverting back to the app developer. You can't expect, now, that paying Redhat or Canonical for a support contract will mean that Redhat/Canonical will be required to rush you patches for your app software. It never worked this way anywhere else; Microsoft and Apple aren't responsible for patching the vulnerabilities in the apps in their ecosystems. (Even the ones you buy through their stores!) The Linux world is just coming back to parity with that. Now, on the other hand, system components—things the OS itself depends on—still need to be patched by the OS manufacturer. Microsoft still delivers IE patches; Apple still delivers Webkit patches. Because those are fundamentally system components, used by the OS to do things like drawing notification dialogs. Those components happen to come with apps, but the system component and the app are decoupled; there's no reason the version of Webkit the OS uses, and the version of Webkit Safari uses, need to be the same. And they're not: you can download a fresh Webkit from Webkit.org and Safari will pick it up and use it. Apple, thus, only takes SLA-responsibility for the system-component Webkit—not the "app Webkit." The same is (soon to be) true for Linux distro-makers. --- The near-term effect of all this, of course, isn't that app developers universally pick up the maintenance-contract stone and start carrying it. Most have spent too long in the idyllic world of "downstream support" to realize, right away, what this shift spells for them. Instead, in the near term, it'll be your responsibility, as a system administrator, to be a release-manager for these container-images. This was always true to some degree, because every stack tends to depend on some non-OS-provided components like Nginx-current or the non-system Ruby. But now it'll be pretty much everything. An interesting incentive this creates is to move your release-management more toward monolithic synchronized releases. If you're managing the releases of all the components in your stack, it's much easier to think of yourself as releasing a whole "system" of co-verified components, rather than independently versioning each one. When you upgrade one component, you bump the version of the system as a whole. This sort of release-management is likely familiar to anyone who has managed an Erlang system. :)
bipin_nag 11y ago
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 11y ago
  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
myztic 11y ago
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 11y ago
  > 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 11y ago
    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."
- myztic 11y ago
mkj 11y ago
"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.
wfunction 11y ago
These sorts of problems wouldn't exist if *nix didn't think everything is a file...
- quasarj 11y ago
  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__ 11y ago
    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 11y ago
      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 11y ago
        > 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?
protomyth 11y ago
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.
phantom_oracle 11y ago
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 11y ago
  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.
- NoGravitas 11y ago
  This really doesn't have anything to do with systemd specifically. Any init system on current linux on x86(-64) will have to deal with the efivars pseudo-filesystem (provided by the kernel), because certain utilities (mainly grub-install) need to write to it. It might be wrong to mount it read-write by default (as systemd does), but other init systems (OpenRC, e.g.) have also mounted it read-write.
x3218 11y ago
The goal of SystemD is to give the authorities total access to all linux systems. This exposing of these lower level components comports with this purpose. You know: the authorities who enforce cunt rights all over the globe, chant "GIRLS NOT BRIDES", imprison men all over the globe, bomb any marry-little-girl cultures, and send you away for any evidence that you actually are thinking of young QT girls. Poettering supports women's rights and feminism ofcourse. He is a piece of shit and it is unfortunate that he and every single one of the people who believe in women's rights is not dead.
x3218 11y ago
The goal of SystemD is to give the authorities total access to all linux systems. This exposing of these lower level components comports with this purpose. You know: the authorities who enforce cunt rights all over the globe, chant "GIRLS NOT BRIDES", imprison men all over the globe, bomb any marry-little-girl cultures, and send you away for any evidence that you actually are thinking of young QT girls. Poettering supports women's rights and feminism ofcourse. He is a piece of shit and it is unfortunate that he and every single one of the people who believe in women's rights is not dead.
x3218 11y ago
The goal of SystemD is to give the authorities total access to all linux systems. This exposing of these lower level components comports with this purpose. You know: the authorities who enforce cunt rights all over the globe, chant "GIRLS NOT BRIDES", imprison men all over the globe, bomb any marry-little-girl cultures, and send you away for any evidence that you actually are thinking of young QT girls. Poettering supports women's rights and feminism ofcourse. He is a piece of shit and it is unfortunate that he and every single one of the people who believe in women's rights is not dead.
x3218 11y ago
Why don't yall rest your mind about all this huckterism from poettering and have a cookie... or rather some libre vidya: For real time strategy: http://lgdb.org/game/0-ad http://lgdb.org/game/0-ad 0 AD For minecraft style: http://www.minetest.net/download http://www.minetest.net/download Mine Test For RPG style: http://www.freedroid.org/news/news-detail/article/merry-christmas-2015-freedroidrpg-016-released/ http://www.freedroid.org/news/news-detail/article/merry-chri... FreeDroid RPG For Platformer Style: https://github.com/SuperTux/supertux/releases/tag/v0.4.0 https://github.com/SuperTux/supertux/releases/tag/v0.4.0 SuperTux For FPS style: http://www.lgdb.org/game/chaosesque-anthology http://www.lgdb.org/game/chaosesque-anthology ChaosEsque Anthology (Fork of Xonotic) For 2d Physics sandbox: http://powdertoy.co.uk/ http://powdertoy.co.uk/ Powder Toy Take your mind off this poettering bullshit. They've taken over our thing, line-unix, and there is nothing that we can do about it. Maybe contribute to devuan, if they'll even let you. (Some of the blowhards there on the mailing list don't even want security-hardening scripts in Devuan because "A real unix admin knows how to do the 100+ changes HIMSELF (EVERYTIME!!!)". Fucking faggot. (S something)...
x3218 11y ago
Hans Reiser did the correct thing. He just didn't do enough of it.
Selm 11y ago
>The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly. What the computer industry wants is to enable their masters total access to every though you've expressed on your personal machine, so they may then go and arrest and imprison (or kill if the mmmaaalllleeee doesn't come quietly) any mmmmaaaalllleeee that is opposed to their beliefs. Their beliefs are summed up in statements such as "GIRLS NOT BRIDES" and the various anti-hate-speech laws and anti-sedition that are used to disempower males around the globe. Part of the strategy is to ensure that only peneterable machines exist in the hands of we, the maaaallleeeee cattle. Thus vendor-lock in with windows, the corruption of linux via Systemd, the abandonment of security hardenening setup scripts such as Bastille-Linux, et al. The computer industry, being filled with SJW faggots, is just doing it's "nerd" job of supporting women's rights and suppressing the rest of the men in the world who would like to marry cute young girls as they could in the past* They are like the euniches of old. >In the United States, as late as the 1880s most States set the minimum age at 10-12, (in Delaware it was 7 in 1895).[8] Inspired by the "Maiden Tribute" female reformers in the US initiated their own campaign[9] which petitioned legislators to raise the legal minimum age to at least 16, with the ultimate goal to raise the age to 18. The campaign was successful, with almost all states raising the minimum age to 16-18 years by 1920. >Also: see: Deuteronomy chapter 22 verses 28-29, hebrew allows men to rape girl children and keep them: thus man + girl is obviously fine. Feminists are commanded to be killed as anyone enticing others to follow another ruler/judge/god is to be killed as-per Deuteronomy. It is wonderful when this happens from time to time: celebrate) >The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly. What the computer industry wants is to enable their masters total access to every though you've expressed on your personal machine, so they may then go and arrest and imprison (or kill if the mmmaaalllleeee doesn't come quietly) any mmmmaaaalllleeee that is opposed to their beliefs. Their beliefs are summed up in statements such as "GIRLS NOT BRIDES" and the various anti-hate-speech laws and anti-sedition that are used to disempower males around the globe. Part of the strategy is to ensure that only peneterable machines exist in the hands of we, the maaaallleeeee cattle. Thus vendor-lock in with windows, the corruption of linux via Systemd, the abandonment of security hardenening setup scripts such as Bastille-Linux, et al. The computer industry, being filled with SJW faggots, is just doing it's "nerd" job of supporting women's rights and suppressing the rest of the men in the world who would like to marry cute young girls as they could in the past* They are like the euniches of old. >In the United States, as late as the 1880s most States set the minimum age at 10-12, (in Delaware it was 7 in 1895).[8] Inspired by the "Maiden Tribute" female reformers in the US initiated their own campaign[9] which petitioned legislators to raise the legal minimum age to at least 16, with the ultimate goal to raise the age to 18. The campaign was successful, with almost all states raising the minimum age to 16-18 years by 1920. >Also: see: Deuteronomy chapter 22 verses 28-29, hebrew allows men to rape girl children and keep them: thus man + girl is obviously fine. Feminists are commanded to be killed as anyone enticing others to follow another ruler/judge/god is to be killed as-per Deuteronomy. It is wonderful when this happens from time to time: celebrate)
cyphar 11y ago
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
JdeBP 11y ago
See also https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 .
Qantourisc 11y ago
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.
libeclipse 11y ago
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.
JdeBP 11y ago
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/e52b5f59c22283b22e2b5a0d2ab9de6b92a73ebf/init.d/sysfs.in#L99 https://github.com/OpenRC/openrc/blob/e52b5f59c22283b22e2b5a... * https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169eaa465ef90349d1ee367e https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169e... 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 11y ago
  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.
peterwwillis 11y ago
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.

422 points by wsx 11y ago

finid 11y ago

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-to-your-linuxbsd-machine http://linuxbsdos.com/2012/04/29/what-will-rm-rf-actually-do... was published.

wsx 11y ago

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.

detaro 11y ago

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

necessity 11y ago

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

wsx 11y ago
It's very funny until they drop BIOS compatibility mode from new machines.
- wtallis 11y ago
  As long as they still let you turn off Secure Boot, I don't see why you can't just put a BIOS CSM in your EFI system partition and load it before proceeding with business as usual.
mwfunk 11y ago
As a human being, I don't chuckle at other people's pain, nor do I brag about it.
- simoncion 11y ago
  > 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 11y ago
    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.
- xyzzy4 11y ago
  You don't like the movie Dumb and Dumber?
- deleted 11y ago
  [deleted]
JdeBP 11y ago
As (presumably) an ACPI user, you should rather be sympathizing.
deleted 11y ago
[deleted]

userbinator 11y ago

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.

bittermang 11y ago
The problem is the Linux based boot loader that circumvents Windows Activation Technology. I am convinced that -- and that alone -- is why we live with UEFI.
- jgord 11y ago
  au contraire, the problem is windows thinks it owns the machine I bought for the sole purpose of running linux.
  - knowaveragejoe 11y ago
    It's poorly phrased, but I think he is agreeing with you.
  - deleted 11y ago
    [deleted]
- 11y ago

DblPlusUngood 11y ago

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 11y ago
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.
- yrro 11y ago
  You can do exactly the same thing on Windows by calling SetFirmwareEnvironmentVariable. The problem is on the firmware side!
  - NamTaf 11y ago
    Yeh I wasn't laying blame on the *nix side of things either. No OS should be able to do this because the OS shouldn't have that level of control over the system it's sittting upon. Firmware absolutely shouldn't fail to a broken state. If you hose some configuration and it crashes, it should revert back to a known good configuration e.g.: a factory reset / fail-safe configuration. You shouldn't be able to hose it completely except through special equipment, for example by connecting to system programming terminals on the motherboard with external hardware. The fact that a higher-level system can damage a lower-level system is just bad design.
    - dh997 11y ago
      Dangerous tasks should have the most safety interlocks, but not require manual, needy attention that makes it harder to automate deployments. This edge-case functionality may still be useful for self-destructing / remote bricking sensitive embedded devices. efidestructivecmd opts... --really-brick-myself-and-catch-fire # fire optional

im2w1l 11y ago

> 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 11y ago
Probably not in this case, because affected systems don't give even a slightest sign of life.

Cartwright2 11y ago

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)

nextos 11y ago
He needs one, and you shouldn't get downvoted for saying this. Systemd has brought lots of good things to Linux, but tons of bloat and insanity too. I'm quite scared because the next thing they seem to be tackling is one of the core things that makes Linux so nice, package management [1]. They intend to container-ize everything. While that might be in principle good (NixOS got it right), their solution is likely to end up being a mess: no control over container contents. Imagine a critical security bug on e.g. OpenSSL. Good luck patching all your dozens of unmanaged containers running different OpenSSL library instances. [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...
- dh997 11y ago
  Reinvention without purpose often appears to take credit for fixing "old==bad" and dodging blame for churn, usually ortogonal of understanding of users' needs: enterprise, industrial embedded, IoT, desktop, mobile, etc. and the actual pain and cost of change at large scale (beyond people one knows and non developers).
- derefr 11y ago
  From my perspective, containers just make explicit what's always been true: the library dependencies linked into the "release" of an "app" need to be stewarded by the app developers, rather than the OS distributor. System components are owned by the system maintainer, but apps are owned by their developers, and the SLAs are separate. If Nginx, for example, has a security flaw, it's properly Nginx's job to make a new container. That flaw might be because of Nginx's dependency on OpenSSL, but it might also be because of a vulnerability in Nginx itself. Nginx (and every other "app" developer) needs the process in place to get new releases out in the latter case; if they have that process, there's no reason to not apply it also to the former case. Distro maintainers have been picking up the slack of creating "security releases" for app software for decades now, but they only do it because app developers were unwilling to take on the responsibility of maintaining packages in several different package ecosystems. App developers are not nearly as timid when it comes to container-image releases, since it's just the one QA process rather than five. So, properly, the responsibility—and the SLA—is reverting back to the app developer. You can't expect, now, that paying Redhat or Canonical for a support contract will mean that Redhat/Canonical will be required to rush you patches for your app software. It never worked this way anywhere else; Microsoft and Apple aren't responsible for patching the vulnerabilities in the apps in their ecosystems. (Even the ones you buy through their stores!) The Linux world is just coming back to parity with that. Now, on the other hand, system components—things the OS itself depends on—still need to be patched by the OS manufacturer. Microsoft still delivers IE patches; Apple still delivers Webkit patches. Because those are fundamentally system components, used by the OS to do things like drawing notification dialogs. Those components happen to come with apps, but the system component and the app are decoupled; there's no reason the version of Webkit the OS uses, and the version of Webkit Safari uses, need to be the same. And they're not: you can download a fresh Webkit from Webkit.org and Safari will pick it up and use it. Apple, thus, only takes SLA-responsibility for the system-component Webkit—not the "app Webkit." The same is (soon to be) true for Linux distro-makers. --- The near-term effect of all this, of course, isn't that app developers universally pick up the maintenance-contract stone and start carrying it. Most have spent too long in the idyllic world of "downstream support" to realize, right away, what this shift spells for them. Instead, in the near term, it'll be your responsibility, as a system administrator, to be a release-manager for these container-images. This was always true to some degree, because every stack tends to depend on some non-OS-provided components like Nginx-current or the non-system Ruby. But now it'll be pretty much everything. An interesting incentive this creates is to move your release-management more toward monolithic synchronized releases. If you're managing the releases of all the components in your stack, it's much easier to think of yourself as releasing a whole "system" of co-verified components, rather than independently versioning each one. When you upgrade one component, you bump the version of the system as a whole. This sort of release-management is likely familiar to anyone who has managed an Erlang system. :)

bipin_nag 11y ago

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 11y ago
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

myztic 11y ago

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 11y ago
> 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 11y ago
  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."
myztic 11y ago

mkj 11y ago

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

wfunction 11y ago

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

quasarj 11y ago
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__ 11y ago
  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 11y ago
    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 11y ago
      > 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?

protomyth 11y ago

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.

phantom_oracle 11y ago

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 11y ago
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.
NoGravitas 11y ago
This really doesn't have anything to do with systemd specifically. Any init system on current linux on x86(-64) will have to deal with the efivars pseudo-filesystem (provided by the kernel), because certain utilities (mainly grub-install) need to write to it. It might be wrong to mount it read-write by default (as systemd does), but other init systems (OpenRC, e.g.) have also mounted it read-write.

x3218 11y ago

The goal of SystemD is to give the authorities total access to all linux systems. This exposing of these lower level components comports with this purpose. You know: the authorities who enforce cunt rights all over the globe, chant "GIRLS NOT BRIDES", imprison men all over the globe, bomb any marry-little-girl cultures, and send you away for any evidence that you actually are thinking of young QT girls. Poettering supports women's rights and feminism ofcourse. He is a piece of shit and it is unfortunate that he and every single one of the people who believe in women's rights is not dead.

x3218 11y ago

Why don't yall rest your mind about all this huckterism from poettering and have a cookie... or rather some libre vidya: For real time strategy: http://lgdb.org/game/0-ad http://lgdb.org/game/0-ad 0 AD For minecraft style: http://www.minetest.net/download http://www.minetest.net/download Mine Test For RPG style: http://www.freedroid.org/news/news-detail/article/merry-christmas-2015-freedroidrpg-016-released/ http://www.freedroid.org/news/news-detail/article/merry-chri... FreeDroid RPG For Platformer Style: https://github.com/SuperTux/supertux/releases/tag/v0.4.0 https://github.com/SuperTux/supertux/releases/tag/v0.4.0 SuperTux For FPS style: http://www.lgdb.org/game/chaosesque-anthology http://www.lgdb.org/game/chaosesque-anthology ChaosEsque Anthology (Fork of Xonotic) For 2d Physics sandbox: http://powdertoy.co.uk/ http://powdertoy.co.uk/ Powder Toy Take your mind off this poettering bullshit. They've taken over our thing, line-unix, and there is nothing that we can do about it. Maybe contribute to devuan, if they'll even let you. (Some of the blowhards there on the mailing list don't even want security-hardening scripts in Devuan because "A real unix admin knows how to do the 100+ changes HIMSELF (EVERYTIME!!!)". Fucking faggot. (S something)...

x3218 11y ago

Hans Reiser did the correct thing. He just didn't do enough of it.

Selm 11y ago

>The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly. What the computer industry wants is to enable their masters total access to every though you've expressed on your personal machine, so they may then go and arrest and imprison (or kill if the mmmaaalllleeee doesn't come quietly) any mmmmaaaalllleeee that is opposed to their beliefs. Their beliefs are summed up in statements such as "GIRLS NOT BRIDES" and the various anti-hate-speech laws and anti-sedition that are used to disempower males around the globe. Part of the strategy is to ensure that only peneterable machines exist in the hands of we, the maaaallleeeee cattle. Thus vendor-lock in with windows, the corruption of linux via Systemd, the abandonment of security hardenening setup scripts such as Bastille-Linux, et al. The computer industry, being filled with SJW faggots, is just doing it's "nerd" job of supporting women's rights and suppressing the rest of the men in the world who would like to marry cute young girls as they could in the past* They are like the euniches of old. >In the United States, as late as the 1880s most States set the minimum age at 10-12, (in Delaware it was 7 in 1895).[8] Inspired by the "Maiden Tribute" female reformers in the US initiated their own campaign[9] which petitioned legislators to raise the legal minimum age to at least 16, with the ultimate goal to raise the age to 18. The campaign was successful, with almost all states raising the minimum age to 16-18 years by 1920. >Also: see: Deuteronomy chapter 22 verses 28-29, hebrew allows men to rape girl children and keep them: thus man + girl is obviously fine. Feminists are commanded to be killed as anyone enticing others to follow another ruler/judge/god is to be killed as-per Deuteronomy. It is wonderful when this happens from time to time: celebrate) >The computer industry really needs to overhaul how system firmware is developed, tested, and deployed. Linux devs and users aren't the only ones feeling the pain; they're just the ones who are both skilled enough to trace the problem back to firmware, and inclined to rant about it publicly. What the computer industry wants is to enable their masters total access to every though you've expressed on your personal machine, so they may then go and arrest and imprison (or kill if the mmmaaalllleeee doesn't come quietly) any mmmmaaaalllleeee that is opposed to their beliefs. Their beliefs are summed up in statements such as "GIRLS NOT BRIDES" and the various anti-hate-speech laws and anti-sedition that are used to disempower males around the globe. Part of the strategy is to ensure that only peneterable machines exist in the hands of we, the maaaallleeeee cattle. Thus vendor-lock in with windows, the corruption of linux via Systemd, the abandonment of security hardenening setup scripts such as Bastille-Linux, et al. The computer industry, being filled with SJW faggots, is just doing it's "nerd" job of supporting women's rights and suppressing the rest of the men in the world who would like to marry cute young girls as they could in the past* They are like the euniches of old. >In the United States, as late as the 1880s most States set the minimum age at 10-12, (in Delaware it was 7 in 1895).[8] Inspired by the "Maiden Tribute" female reformers in the US initiated their own campaign[9] which petitioned legislators to raise the legal minimum age to at least 16, with the ultimate goal to raise the age to 18. The campaign was successful, with almost all states raising the minimum age to 16-18 years by 1920. >Also: see: Deuteronomy chapter 22 verses 28-29, hebrew allows men to rape girl children and keep them: thus man + girl is obviously fine. Feminists are commanded to be killed as anyone enticing others to follow another ruler/judge/god is to be killed as-per Deuteronomy. It is wonderful when this happens from time to time: celebrate)

cyphar 11y ago

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

JdeBP 11y ago

See also https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 .

Qantourisc 11y ago

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.

libeclipse 11y ago

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.

JdeBP 11y ago

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/e52b5f59c22283b22e2b5a0d2ab9de6b92a73ebf/init.d/sysfs.in#L99 https://github.com/OpenRC/openrc/blob/e52b5f59c22283b22e2b5a... * https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169eaa465ef90349d1ee367e https://github.com/OpenRC/openrc/commit/02a7d3573d551c5d169e... 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 11y ago
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.

peterwwillis 11y ago

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.