Most active commenters

    ←back to thread

    Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

    (git.kernel.org)
    279 points the_why_of_y | 18 comments | 22 Feb 16 18:08 UTC | HN request time: 0.227s | source | bottom
    1. tvbn ◴[22 Feb 16 19:15 UTC] No.11153444[source]▶
    They disabled kernel feature to prevent systemd bug? It doesn't make any sense.
    replies(5): >>11153459 #>>11153462 #>>11153477 #>>11153479 #>>11153602 #
    2. cmurf ◴[22 Feb 16 19:17 UTC] No.11153459[source]▶
    They disabled a kernel feature to work around a firmware bug (which not all computers have). The firmware really shouldn't allow modification of things that will cause the firmware to permanently face plant.
    3. cbd1984 ◴[22 Feb 16 19:18 UTC] No.11153462[source]▶
    This is a firmware bug. How is it related to systemd?
    4. Mic92 ◴[22 Feb 16 19:20 UTC] No.11153477[source]▶
    It is not disabled, but a immutable flag is set. You can still delete it by applying `chattr -i` first
    5. kbenson ◴[22 Feb 16 19:20 UTC] No.11153479[source]▶
    It's not a systemd bug, it was just exposed by systemd. This was what most everyone seemed to completely miss in the prior exchanges.

    Another thing that was missed was that Lennart wasn't being unreasonable, nor was he saying it wasn't a problem (he specifically stated the opposite, in fact). I had a feeling at the time (based on his responses) that the reason he wasn't specifically stating he was going to fix it or open a bug report for it in systemd was that he was going to push it up-stack to a more appropriate place, and it looks like that's what happened.

    replies(2): >>11153687 #>>11153716 #
    6. pavanky ◴[22 Feb 16 19:36 UTC] No.11153602[source]▶
    It's not a systemd bug, it is not a kernel bug. It was a firmware bug. It is usually the Linux kernel that "fixes" these idiotic issues when vendors don't implement something correctly.
    7. captainmuon ◴[22 Feb 16 19:47 UTC] No.11153687[source]▶
    I'd say it wasn't a bug in systemd's implementation, it was a bug in the design of systemd. Why require that evivarfs be mounted at runtime? You could easily make it so that it is only mounted at boot time if neccessary, or only when you run a tool that wants to write to EFI.

    I'd expect file operations to only permanently affect storage devices per default. Sure you can mount almost anything as a file in Unix, but to automatically mount more than necessary is bad design. It's like placing mystery files in the filesystem, and when a curious user deletes or modifies them, they loose their monitor's color profile, there printer's firmware, or all of their GMail attachments. You could say it was the user's fault to mess with it, but I'd say it's weird to expose such things as files (unless explicitly asked for by the user or a tool).

    replies(1): >>11153810 #
    8. eeZi ◴[22 Feb 16 19:52 UTC] No.11153716[source]▶
    > Another thing that was missed was that Lennart wasn't being unreasonable, nor was he saying it wasn't a problem (he specifically stated the opposite, in fact). I had a feeling at the time (based on his responses) that the reason he wasn't specifically stating he was going to fix it or open a bug report for it in systemd was that he was going to push it up-stack to a more appropriate place, and it looks like that's what happened.

    This. It's really hard to blame this on systemd (not that people didn't try anyway).

    replies(1): >>11153819 #
    9. sandGorgon ◴[22 Feb 16 20:02 UTC] No.11153810{3}[source]▶
    EVERY single init system mounts it's rw. It is not specific to systemd. There are lots of situations where EFI boot variables need to be set by the OS.

    Systemd is as consistent as upstart in this.

    replies(1): >>11153922 #
    10. 5ilv3r ◴[22 Feb 16 20:03 UTC] No.11153819{3}[source]▶
    My bsd init and sysv init machines do not have this issue. They don't automount every damn filesystem they see at boot for no reason.
    replies(2): >>11154317 #>>11157755 #
    11. Sanddancer ◴[22 Feb 16 20:16 UTC] No.11153922{4}[source]▶
    No. Sane operating systems don't present UEFI variables as a filesystem. Their structure, their contents, everything are not files. Period. efivarfs doesn't expose metadata regarding when variables are visible, does't expose any sort of interface to present a private key for managing secure variables, etc. It's just a bad, broken idea that should be completely removed.
    replies(3): >>11154072 #>>11154135 #>>11156258 #
    12. mjg59 ◴[22 Feb 16 20:35 UTC] No.11154072{5}[source]▶
    > does't expose any sort of interface to present a private key for managing secure variables

    Nor does UEFI. The key is just provided as part of the SetVariable() payload.

    13. the_mitsuhiko ◴[22 Feb 16 20:43 UTC] No.11154135{5}[source]▶
    > No. Sane operating systems don't present UEFI variables as a filesystem

    Probably. But that's not systemd's fault.

    replies(1): >>11155023 #
    14. ambrice ◴[22 Feb 16 21:09 UTC] No.11154317{4}[source]▶
    It seems to me like it's a bad thing that an accidental rm in an efivarfs filesystem can brick the system, regardless of whether the filesystem was automounted or not.
    15. Sanddancer ◴[22 Feb 16 22:54 UTC] No.11155023{6}[source]▶
    The systemd developers could have said that they wanted no part of that madness, and chosen not to automatically mount it. Someone else's bad decision doesn't absolve one from their own bad decisions.
    replies(1): >>11156340 #
    16. sandGorgon ◴[23 Feb 16 03:21 UTC] No.11156258{5}[source]▶
    I'm not qualified to comment on that - but this is the core of Linux: everything is a file.

    You may want to call Linux as a crazy operating system , but then you are veering close to Godwins Law anyway.

    17. cbd1984 ◴[23 Feb 16 03:41 UTC] No.11156340{7}[source]▶
    You're really looking for a way to blame systemd.
    18. EmanueleAina ◴[23 Feb 16 09:54 UTC] No.11157755{4}[source]▶
    Windows does not have this issue either.

    But on sysvinit if you mount efivars rw for any reason and your hands slip a bit a stray `rm` could still brick your motherboard, so it's not really fair to say that without automounting the issue goes away.