38 ms·

They disabled kernel feature to prevent systemd bug? It doesn't make any sense.

by tvbn 11y ago

cmurf 11y ago
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.
cbd1984 11y ago
This is a firmware bug. How is it related to systemd?
Mic92 11y ago
It is not disabled, but a immutable flag is set. You can still delete it by applying `chattr -i` first
kbenson 11y ago
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.
- captainmuon 11y ago
  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.
      - 11y ago
- eeZi 11y ago
  > 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).
  - 5ilv3r 11y ago
    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.
    - ambrice 11y ago
      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.
    - EmanueleAina 11y ago
      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.
pavanky 11y ago
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.

They disabled kernel feature to prevent systemd bug? It doesn't make any sense.

by tvbn 11y ago

They disabled kernel feature to prevent systemd bug? It doesn't make any sense.

cmurf 11y ago

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.

cbd1984 11y ago

This is a firmware bug. How is it related to systemd?

Mic92 11y ago

It is not disabled, but a immutable flag is set. You can still delete it by applying `chattr -i` first

kbenson 11y ago

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.

captainmuon 11y ago
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.
    - 11y ago
eeZi 11y ago
> 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).
- 5ilv3r 11y ago
  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.
  - ambrice 11y ago
    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.
  - EmanueleAina 11y ago
    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.

pavanky 11y ago

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.