Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Tuesday February 09 2016, @02:27AM   Printer-friendly
from the why-oh-why dept.

A number of users have reported that running "rm --no-preserve-root -rf /" not only deletes all their files (as expected), but also permanently bricks their computers (which is not). Tracing the issue revealed that the ultimate cause was that SystemD mounted the EFI pseudo-fs as read-write even when this FS was not listed in fstab, and deleting certain files in this pseudo-fs causes certain buggy, but very common, firmware not to POST anymore. A user reported this bug on SystemD's GitHub issue tracker, asking that the FS be mounted read-only instead of read-write, and said bug was immediately closed as invalid. The comment thread for the bug was locked shortly after. Discuss.

Links:
https://github.com/systemd/systemd/issues/2402
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by KilroySmith on Tuesday February 09 2016, @03:57AM

    by KilroySmith (2113) on Tuesday February 09 2016, @03:57AM (#301159)

    Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?

    The fact that there's a firmware bug that gets triggered by this incorrect behavior doesn't excuse the incorrect behavior.

    But, perhaps there's a good reason for this behavior and I simply don't know what it is.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=3, Overrated=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Informative) by Anonymous Coward on Tuesday February 09 2016, @04:23AM

    by Anonymous Coward on Tuesday February 09 2016, @04:23AM (#301175)

    Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?

    Yes, you are ignorant. SystemD ain't deleting anything. ALL it is doing is mounting the EFI filesystem read-write - exactly as the title of the submission says.

    Any deletion of EFI variables is coming from somewhere else. Like doing "rm -rf /"

    • (Score: 5, Touché) by maxwell demon on Tuesday February 09 2016, @07:01AM

      by maxwell demon (1608) on Tuesday February 09 2016, @07:01AM (#301236) Journal

      And why does it mount the EFI file system read/write, when not requested to be the user?

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 4, Insightful) by TheReaperD on Tuesday February 09 2016, @08:56AM

        by TheReaperD (5556) on Tuesday February 09 2016, @08:56AM (#301289)

        It seems to be trying to do something similar to how PRAM works on MACs. A reserved space in the firmware that software can write data. I personally think that it is a really horrible idea but, there seems to be a lot of demand from some software vendors to be able to write data to hardware. Though I can see valid uses for it, such as storing your software serial numbers for reinstall (such as Windows 8/10) I see far more opportunities for abuse.

        --
        Ad eundum quo nemo ante iit
        • (Score: 2) by maxwell demon on Tuesday February 09 2016, @10:47AM

          by maxwell demon (1608) on Tuesday February 09 2016, @10:47AM (#301325) Journal

          Well, as long as I, as user, can decide whether I want to enable it, I'm OK with such support. But if it is enabled unconditionally, for providing functionality I'm not even planning to use, that's not OK.

          --
          The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 0) by Anonymous Coward on Wednesday February 10 2016, @09:52PM

          by Anonymous Coward on Wednesday February 10 2016, @09:52PM (#302395)

          > there seems to be a lot of demand from some software vendors to be able to write data to hardware
          and systemd bends over, while $rookie_programmer_writing_code_in_his_spare_time would have had more security concerns. I am not surprised at systemd devs, overenthusiasm and wanting to change the world is understandable. But, fuck, what about RedHat? They write the drivers for linux FFS

      • (Score: 1, Insightful) by Anonymous Coward on Tuesday February 09 2016, @02:24PM

        by Anonymous Coward on Tuesday February 09 2016, @02:24PM (#301417)

        > And why does it mount the EFI file system read/write, when not requested to be the user?

        Why does it mount /dev read-write when not requested to by the user?

        You can nit-pick anything to death if you are motivated. None of this would be an issue if the firmware wasn't buggy in the first place.

        • (Score: 2) by fido_dogstoyevsky on Tuesday February 09 2016, @09:50PM

          by fido_dogstoyevsky (131) <axehandleNO@SPAMgmail.com> on Tuesday February 09 2016, @09:50PM (#301699)

          None of this would be an issue if the firmware wasn't buggy in the first place.

          And if systemd wasn't sloppy enough to let that sort of bug through.

          --
          It's NOT a conspiracy... it's a plot.
        • (Score: 2) by HiThere on Wednesday February 10 2016, @04:32AM

          by HiThere (866) Subscriber Badge on Wednesday February 10 2016, @04:32AM (#301920) Journal

          Sorry, but theres *LOTS* of buggy hardware out there. When software is designed to run on that hardware it is *expected* to compensate for those bugs.

          Yes, it's a hardware bug. It's **ALSO** a software bug.

          --
          Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
      • (Score: 2, Interesting) by Arik on Tuesday February 09 2016, @06:25PM

        by Arik (4543) on Tuesday February 09 2016, @06:25PM (#301575) Journal
        "And why does it mount the EFI file system read/write, when not requested to be the user?"

        Because it's Poettering-ware and that's his philosophy. The 'user' is not intended to be a system administrator, the 'user' is conceived of as completely innocent of all computer skills and the system will be designed to ensure that s/he stays that way. It's nearly inconceivable for him to permit any increase in user control, in any area, because the entire thrust of his development is to disempower the user in every way possible.

        Also, I haven't confirmed this so it may just be a rumor, but there was talk about using the R/W EFI disk to enable a remote-control reboot to windows on a dual-boot machine. Maybe that's considered a killer app over in systemD land?
        --
        If laughter is the best medicine, who are the best doctors?
      • (Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:34PM

        by Anonymous Coward on Tuesday February 09 2016, @06:34PM (#301582)

        The last comment to the bug report, by Mr. Poettering, explains why writes are enabled:

        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.

        • (Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @06:41PM

          by maxwell demon (1608) on Tuesday February 09 2016, @06:41PM (#301587) Journal

          And when I don't want to issue that command, then there's no point in having it writeable.

          --
          The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 5, Informative) by Immerman on Tuesday February 09 2016, @04:28AM

    by Immerman (3985) on Tuesday February 09 2016, @04:28AM (#301177)

    As I understand it SystemD is deleting nothing, it's simply mounting EFI in the file system as read-write.

    If YOU then tell the OS to delete everything in the file system, that command obviously interacts with the RW-mounted firmware in potentially catastrophic manner, if neither the motherboard nor filesystem have appropriate safeguards in place.

    Basically, you could cause this exact same problem on a SystemD-free computer simply by mounting the EFI read-write by hand. SystemD is simply taking one step that primes the system to expose the bug in other code IF you proceed to do something that is generally (but not always) considered a Very Bad Idea.

    • (Score: 2) by VLM on Tuesday February 09 2016, @01:05PM

      by VLM (445) Subscriber Badge on Tuesday February 09 2016, @01:05PM (#301390)

      If YOU then tell

      Or a bug.

      In this bifurcated era where smart people use pkgng and nix and whatever else and the lowliest of the noobs think "wget http:root_me_root_me_harder.sh | /bin/bash" is also a package manager, there was an example I don't remember and for some reason can't google where some commercial software shell script accidentally pulled a "rm -Rf /"

      • (Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @11:25PM

        by Anonymous Coward on Tuesday February 09 2016, @11:25PM (#301764)
        That was Steam. When uninstalling, it would "rm -rf steamdir" -- which is fine as long as steamdir actually points to your Steam directory.
      • (Score: 2) by Immerman on Wednesday February 10 2016, @03:11PM

        by Immerman (3985) on Wednesday February 10 2016, @03:11PM (#302163)

        Indeed. I didn't mean to imply that you had to do it intentionally or directly, only that the user had to independently initiate the action, and that there was nothing systemD-specific about the problem.

  • (Score: 5, Informative) by KilroySmith on Tuesday February 09 2016, @04:36AM

    by KilroySmith (2113) on Tuesday February 09 2016, @04:36AM (#301181)

    OK, so this was so confusing to me that I actually spent 15 minutes reading about it.

    Linux allows mounting the EFI pseudo-FS. Everybody agrees this is a good thing.
    SystemD always mounts it, and mounts it RW by default, because:

    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.

    When you do your "rm --no-preserve-root -rf /", the EFI filesystem starts erasing stuff - as you've requested. If, however, you're new to a SystemD-equipped system, and aren't used to the EFI FS being mounted, you will unexpectedly start screwing with the EFI FS.

    A tempest in a teapot. The only problem I see here is that the choice of default mount for the EFI FS - if they had chosen ro, there'd be no issue, and "systemctl reboot --firmware" could remount the FS RW for the length of time necessary to set the variable prior to rebooting. The choice of rw is dangerous even in the case where the EFI BIOS doesn't misbehave, because unexpected write access to the BIOS variables shouldn't occur.

    • (Score: 2) by jimshatt on Tuesday February 09 2016, @08:49AM

      by jimshatt (978) on Tuesday February 09 2016, @08:49AM (#301286) Journal
      And even then, you'll only brick the BIOS when the implementation is crappy anyway. I'm not sure mounting rw is a good idea, but it's not a bug per se.
      • (Score: 2) by HiThere on Wednesday February 10 2016, @04:39AM

        by HiThere (866) Subscriber Badge on Wednesday February 10 2016, @04:39AM (#301921) Journal

        I think that leaving it mounted rw when you don't need it so counts as a bug. But certainly refusing to fix the problem when it starts bricking systems counts as a bug. And an extremely bad one, though the severity of the bug is not so much in the bug itself as in the administrative process holding it in place.

        Prior to this event I had thought that the problems being reported about systemd were all "teething problems" and that they would go away as the software matured. Now It looks more like they are being intentionally frozen in place, though one may speculate about the reasons for why this is being done.

        --
        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    • (Score: 5, Insightful) by pTamok on Tuesday February 09 2016, @11:14AM

      by pTamok (3042) on Tuesday February 09 2016, @11:14AM (#301336)

      There is a principle in security, which is the 'principle of least access' - you get the minimum access needed to do your job.

      In this case, systemd opening the efi filesystem as rw when it didn't need to violates that principle: it should, as you point out later in your post, only open the filesystem for rw when it _needs_ to write, given what this pseudo filesystem is actually for.

      If you think this argument is wrong, reflect on why some people prefer to use strongly typed languages. In principle, you can write everything in self-modifying assembler, and treat pointers as integers and have all sorts of fun - the point is not whether you can do it, the point is whether or not you should.

      Having sane defaults is a good thing.

    • (Score: 5, Insightful) by Thexalon on Tuesday February 09 2016, @03:08PM

      by Thexalon (636) on Tuesday February 09 2016, @03:08PM (#301440)

      You know, this is the kind of response that truly bothers me. Here we have:
      - A known problem with a pretty clear description of what's wrong.
      - An obvious solution, namely to mount read-write only when you actually need to, because it's dangerously stupid to have it read-write all the time (as demonstrated by the problem)

      And the response from Lennart Poettering is "won't fix, because it might require a bit of extra code for a single obscure feature". That's not the response to a bug that gives me any kind of confidence that Lennart should be in charge of anything remotely resembling a critical component of most major Linux distributions.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
      • (Score: 0) by Anonymous Coward on Friday February 19 2016, @02:55AM

        by Anonymous Coward on Friday February 19 2016, @02:55AM (#306694)

        You should have seen him defending breaking su because Pulseaudio somehow didn't work alongside it otherwise.

        This by using systemd's pam module to alter a xdg environment variable if your ran su or su -l, so that anything that dependend on that variable to tell them where to stash their settings file would stop the initial users settings file.

        His defense was that su was a broken concept.

        Then later someone offered him a fix to pulseaudio so that the variable change was no longer needed. But this happened outside the bug report discussion, and the people following it had to rely on third parties to keep an eye on the various mailing lists. Eventually i think the bug report died because it was tired to a Fedora version that was no longer supported.

        Then they introduce functionality to systemd that mimics su using Linux namespaces/containers.

        Seriously, the whole systemd thing is a mishmash of OSX-isms, Solaris idolation, and an attempt to bypass Torvalds on kernel details by countermanding them via the init process (disabling sysreq combos, changing mount defaults, and the list keeps growing).