3 ms·

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 ma

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

sandGorgon 11y ago
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.
- Sanddancer 11y ago
  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.
  - mjg59 11y ago
    > 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.
  - the_mitsuhiko 11y ago
    > No. Sane operating systems don't present UEFI variables as a filesystem Probably. But that's not systemd's fault.
    - Sanddancer 11y ago
      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.
      - cbd1984 11y ago
        You're really looking for a way to blame systemd.
  - sandGorgon 11y ago
    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.

sandGorgon 11y ago

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.

Sanddancer 11y ago
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.
- mjg59 11y ago
  > 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.
- the_mitsuhiko 11y ago
  > No. Sane operating systems don't present UEFI variables as a filesystem Probably. But that's not systemd's fault.
  - Sanddancer 11y ago
    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.
    - cbd1984 11y ago
      You're really looking for a way to blame systemd.
- sandGorgon 11y ago
  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.