3 ms·

> What userland is it ? And why is it a problem for that userland to mount it itself ? At the very least, efibootmgr. The problem with userland mounting it its

by mjg59 9y ago

> What userland is it ? And why is it a problem for that userland to mount it itself ? At the very least, efibootmgr. The problem with userland mounting it itself is that it has no code to mount it itself because even before systemd everybody mounted the filesystem read/write. > Why would you even write to efi ? Maybe at boot, i don't know, but certainly not while running ? A whole bunch of reasons. Maybe you want something that's tied to the hardware without relying on the OS (eg, tpmtotp). Maybe you want to be able to differentiate between a clean and unclean system shutdown. Maybe you want to indicate that the system should install a firmware update next time it's in boot services. > In my opinion systemd is at fault, as they aim to be the "system" and yet every once in a while prove that they don't know shit. At the time this issue was raised, nobody knew shit. We had no idea that removing certain variables might prevent a machine from booting. If we had done, I'd have written the filesystem differently. > I'm not the one who knows best, on this topic I wrote the code in question. I am one of the people who does know best on this topic. Systemd did nothing wrong.

gatmne 9y ago
Couldn't the filesystem be mounted as read-only during normal operation, and only remounted temporarily as rw when necessary? Tools that write to this filesystem tend to have the necessary privileges to do so. Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision.
- mjg59 9y ago
  > Couldn't the filesystem be mounted as read-only during normal operation, and only remounted temporarily as rw when necessary? Yes, except that none of the tools in question have any support for doing that and so mounting the filesystem read-only rather than read/write would break them. And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?). > Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision. Yes with hindsight that's entirely accurate and it was also my decision and nothing to do with systemd.
  - gens 9y ago
    >Yes, except that none of the tools in question have any support for doing that and so mounting the filesystem read-only rather than read/write would break them. All 4 of the tools (that can even be wrapped in a shell script until they are, as systemd devs say, "fixed"). >And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?). Better to open a window in the morning then to tear down the whole wall forever.
  - gatmne 9y ago
    > now you've still got a window where something can still break everything while the filesystem is mounted read/write I agree, but I'm also sure you would agree that a small window were things can go horribly wrong is much more preferable than than a perpetually open one (sudo and friends stand testament to this). Please bear in mind that my comments are in no way an attack on your person or one directed at systemd. What I want is to find a workable solution or, at the very least, a compromise to prevent this type of issues from occurring. I strongly believe that protecting hardware is a core responsibility of any operating system. Would it be reasonable for me to ask you to coordinate with all the major tool developers to gradually phasing out this behavior? As in both the filesystem and tooling continue to support both current semantics and a newer version until the older semantics can be safely disabled. This is how support tends to get phased out from the kernel for obsolete hardware. Issues of this type have reared their heads many times already and I expect they will continue to occur if the underlying reason is not addressed. As the person who has the ability to do something about it, I urge you to reconsider.
    - mjg59 9y ago
      > I agree, but I'm also sure you would agree that a small window were things can go horribly wrong is much more preferable than than a perpetually open one (sudo and friends stand testament to this). What's even more preferable is a situation where the kernel doesn't let you do the damage in the first place, which is what we have now.
gens 9y ago
So read/write efi is needed to set what happens when the computer boots and to see what state it was/is (relating to boot stuff). To see the state you don't need write permission, obviously. When things are set, they are set by a few very specialized tools. Those are the facts everybody can agree on, right ? Can we also agree that mounting and unmounting the efi filesystem is really easy ? I assume it can be mounted on multiple points. So is there a problem in re/mounting it read/write only when needed ? >At the time this issue was raised, nobody knew shit. We had no idea that removing certain variables might prevent a machine from booting. If we had done, I'd have written the filesystem differently. That's the difference between systemd devs and people capable of critical thinking. You'r a good programmer, if you ask me. (edit: just to be clear, i don't see you as a systemd dev; even if you are (idk), you are not the one making high level design decisions (of which this is, kind of, one))
- mjg59 9y ago
  > Can we also agree that mounting and unmounting the efi filesystem is really easy ? In a race-free way? No. In a way that fails safe? No.

by mjg59 9y ago

gatmne 9y ago

Couldn't the filesystem be mounted as read-only during normal operation, and only remounted temporarily as rw when necessary? Tools that write to this filesystem tend to have the necessary privileges to do so. Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision.

mjg59 9y ago
> Couldn't the filesystem be mounted as read-only during normal operation, and only remounted temporarily as rw when necessary? Yes, except that none of the tools in question have any support for doing that and so mounting the filesystem read-only rather than read/write would break them. And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?). > Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision. Yes with hindsight that's entirely accurate and it was also my decision and nothing to do with systemd.
- gens 9y ago
  >Yes, except that none of the tools in question have any support for doing that and so mounting the filesystem read-only rather than read/write would break them. All 4 of the tools (that can even be wrapped in a shell script until they are, as systemd devs say, "fixed"). >And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?). Better to open a window in the morning then to tear down the whole wall forever.
- gatmne 9y ago
  > now you've still got a window where something can still break everything while the filesystem is mounted read/write I agree, but I'm also sure you would agree that a small window were things can go horribly wrong is much more preferable than than a perpetually open one (sudo and friends stand testament to this). Please bear in mind that my comments are in no way an attack on your person or one directed at systemd. What I want is to find a workable solution or, at the very least, a compromise to prevent this type of issues from occurring. I strongly believe that protecting hardware is a core responsibility of any operating system. Would it be reasonable for me to ask you to coordinate with all the major tool developers to gradually phasing out this behavior? As in both the filesystem and tooling continue to support both current semantics and a newer version until the older semantics can be safely disabled. This is how support tends to get phased out from the kernel for obsolete hardware. Issues of this type have reared their heads many times already and I expect they will continue to occur if the underlying reason is not addressed. As the person who has the ability to do something about it, I urge you to reconsider.
  - mjg59 9y ago
    > I agree, but I'm also sure you would agree that a small window were things can go horribly wrong is much more preferable than than a perpetually open one (sudo and friends stand testament to this). What's even more preferable is a situation where the kernel doesn't let you do the damage in the first place, which is what we have now.

gens 9y ago

So read/write efi is needed to set what happens when the computer boots and to see what state it was/is (relating to boot stuff). To see the state you don't need write permission, obviously. When things are set, they are set by a few very specialized tools. Those are the facts everybody can agree on, right ? Can we also agree that mounting and unmounting the efi filesystem is really easy ? I assume it can be mounted on multiple points. So is there a problem in re/mounting it read/write only when needed ? >At the time this issue was raised, nobody knew shit. We had no idea that removing certain variables might prevent a machine from booting. If we had done, I'd have written the filesystem differently. That's the difference between systemd devs and people capable of critical thinking. You'r a good programmer, if you ask me. (edit: just to be clear, i don't see you as a systemd dev; even if you are (idk), you are not the one making high level design decisions (of which this is, kind of, one))

mjg59 9y ago
> Can we also agree that mounting and unmounting the efi filesystem is really easy ? In a race-free way? No. In a way that fails safe? No.