Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.

SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid

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

linuxrocks123 writes:

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.
SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid | Log In/Create an Account | Top | 145 comments | Search Discussion
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: 5, Insightful) by zocalo on Tuesday February 09 2016, @05:20AM

    by zocalo (302) on Tuesday February 09 2016, @05:20AM (#301197)
    No, it's not systemd's fault. Still, surely an OS, or a key component of it like systemd, should make a reasonable effort to protect the user's system both from themselves and malicious other users? Mounting as RO by default and switching to RW only if required isn't just doing that, it's helping make the OS more secure by default - and that's supposed to be a good thing, right? Unless doing so might cause breakage elsewhere perhaps, but that's not stopped them treating an issue as someone else's problem and NOTABUG before, has it?
    --
    UNIX? They're not even circumcised! Savages!
    Starting Score:    1  point
    Moderation   +4  
       Insightful=3, Informative=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   5  

  • (Score: 5, Insightful) by HonestFlames on Tuesday February 09 2016, @11:53AM

    by HonestFlames (3704) on Tuesday February 09 2016, @11:53AM (#301358)

    This reminds me of all the buggy crap causing suspend/resume fails under Linux for... well I recall it was a long time. It was because of bad / non-standard / crapp DMI table entries in most BIOS.

    Windows just ignored the BIOS stuff and did its own thing, which is why we had the "Windows doesn't have this bug" disussion at the time.

    There is a clear definition between fault and responsibility that should apply to systemd.

    Whilst it is not the fault of systemd that users can brick their systems, it is systemd's responsibility to protect them from this scenario. If someone wants to argue that it shouldn't be systemd's responsibility, then my point is that because systemd know this issue exists and they are in a position to do something about it, they should exercise due caution and put measures in place to limit access into the UEFI data.

    • (Score: 3, Insightful) by zocalo on Tuesday February 09 2016, @12:51PM

      by zocalo (302) on Tuesday February 09 2016, @12:51PM (#301383)
      Exactly. For efficiency's sake, responsibility for any band-aid/workaround/whatever needs to sit as low in the stack as possible to provide the greatest benefit. Since in this case systemd is mounting the UEFI file system in the first place and is PID1, well, it's pretty obvious what's at the bottom of the stack, isn't it? It's not like changing the initial mount to RO and inserting a remount as RW function when needed is a lot of work either, so this could have been a simple fix and way to curry a little favour for the systemd team, but instead they decide to do throw their usual prima donna "not out problem, NOTABUG, WONTFIX, GTFO, thread closed", strop.
      --
      UNIX? They're not even circumcised! Savages!

      • (Score: 0) by Anonymous Coward on Saturday February 20 2016, @11:24PM

        by Anonymous Coward on Saturday February 20 2016, @11:24PM (#307572)

        Bingo. The prima donna act is what gets them all the flack.

        If you check out how Torvalds reacts to something similar, its a case of mea culpa and going through hell to make damn sure it does not happen again.

        You may call it belt and suspenders, or you may call it good engineering practices.

    • (Score: 0) by Anonymous Coward on Saturday February 20 2016, @11:21PM

      by Anonymous Coward on Saturday February 20 2016, @11:21PM (#307569)

      Windows either ignores it, or the bugs come because the hardware was tested only on Windows (and MS can't help themselves going embrace, extend, extinguish on everything they touch).

      Never mind that on Windows, the ODMs can paper over the bugs with drivers.

      What Linux does is pull back the carpets and present to everyone how rotten the floor is.