5 ms·

For those who dont remember, this has happened in the past with systemd - https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issu

For those who dont remember, this has happened in the past with systemd - https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402 At the time systemd got a lot of serious heat and poettering got called names for something that was not systemd's fault to begin with. > To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

JdeBP 9y ago
Already mentioned on this page at https://news.ycombinator.com/item?id=15971180 https://news.ycombinator.com/item?id=15971180 .
dogecoinbase 9y ago
It absolutely was systemd's fault -- systemd regularly half-implements or changes default behavior in ways that "should" be okay, but aren't okay, because they don't know why the fence was built (in the Chestertonian sense). Systems programmers should know the history of their discipline.
- mjg59 9y ago
  I wrote the EFI variables filesystem. It was intended to be mounted read/write. Systemd did nothing wrong whatsoever in mounting it read/write, and mounting it read only would have broken all the existing userland that handles EFI variables.
  - gens 9y ago
    What userland is it ? And why is it a problem for that userland to mount it itself ? Why would you even write to efi ? Maybe at boot, i don't know, but certainly not while running ? Not all the time ? Oh i hope there isn't a single program that continuously writes to efi. 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. EDIT: A program that changes the boot order is all i can think of. (I'm not the one who knows best, on this topic)
    - aseipp 9y ago
      Various tools like efibootmgr talk to efivarfs for several reasons. These settings allow things like secure boot management or various booting modes e.g. it allows you to configure PXE boots, select your next OS, or other things -- if you have UEFI fast boot directly to Linux you can safely configure your machine to boot back into UEFI next time to set options from there, etc. Userspace utilities expect it to be mounted r/w, so changing it unilaterally to read-only will break things if it is intended as a "bug fix" -- which is annoying to ship to users if one fix causes another regression. For example, OpenRC ships it as r/o, but various tools like grub-install do not remount on their own, so they fail strangely. It could be fixed to have userspace mount it, but those things require coordination. Remounting is also a race-y condition for various tools to engage in on their own, for obvious reasons. It also does not change the fact those EFI variables are still exposed as writable once mounted r/w, so even closing the race condition, your system can still be bricked due to a bug. The fix for this in the kernel was to block writes to non-standard UEFI options in efivarfs making them immutable, which prevents accidentally nuking them. This was the actual source of the 'bricking' in the original bug. This is a low-cost fix inside the kernel, which already has to deal with hostile hardware in a million other ways and sanitize various other things to stop all kinds of hardware from crapping itself, just like this. It is also relatively easy for distributions to backport, does not require changing mount semantics for systemd, does not break existing UEFI userspace tools (which would take time to coordinate, and will not manipulate non-standard variables anyway), and stops people from bricking themselves. Logistically, the kernel is really the best and most low-cost place to fix such an issue for everyone, regardless of mount policies on efivarfs in the init system -- in a way that is actually safe for everyone. It would have taken the same time, or more time, to fix it badly (e.g. break userspace tools and require userspace remounts) as fixing it this way. You could level better complaints at UEFI or efivarfs or systemd in general than this one, all things considered... > (I'm not the one who knows best, on this topic) I like how people somehow breathlessly say "systemd developers prove they don't know shit, of course its their fault!!!" and then immediately follow it up with a bunch of fairly basic questions and just admit "oh by the way i don't know what i'm talking about, can anyone tell me otherwise???" systemd annoys me sometimes and I don't like some of its design decisions, but by far its worst "feature" is it causes people who are very unsure of what they are talking about to suddenly become experts about it.
  - tmzt 9y ago
    Could you take a mtools-like approach and not remount it at all, just map it and write from userspace?
    - mjg59 9y ago
      Not with the interface that exists now, no. And we wouldn't really want to leave it up to userspace anyway - there are various firmware-based issues that we want to work around in kernel, and relying on userspace to adopt policy there is unlikely to end well.

JdeBP 9y ago

Already mentioned on this page at https://news.ycombinator.com/item?id=15971180 https://news.ycombinator.com/item?id=15971180 .

dogecoinbase 9y ago

It absolutely was systemd's fault -- systemd regularly half-implements or changes default behavior in ways that "should" be okay, but aren't okay, because they don't know why the fence was built (in the Chestertonian sense). Systems programmers should know the history of their discipline.

mjg59 9y ago
I wrote the EFI variables filesystem. It was intended to be mounted read/write. Systemd did nothing wrong whatsoever in mounting it read/write, and mounting it read only would have broken all the existing userland that handles EFI variables.
- gens 9y ago
  What userland is it ? And why is it a problem for that userland to mount it itself ? Why would you even write to efi ? Maybe at boot, i don't know, but certainly not while running ? Not all the time ? Oh i hope there isn't a single program that continuously writes to efi. 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. EDIT: A program that changes the boot order is all i can think of. (I'm not the one who knows best, on this topic)
  - aseipp 9y ago
    Various tools like efibootmgr talk to efivarfs for several reasons. These settings allow things like secure boot management or various booting modes e.g. it allows you to configure PXE boots, select your next OS, or other things -- if you have UEFI fast boot directly to Linux you can safely configure your machine to boot back into UEFI next time to set options from there, etc. Userspace utilities expect it to be mounted r/w, so changing it unilaterally to read-only will break things if it is intended as a "bug fix" -- which is annoying to ship to users if one fix causes another regression. For example, OpenRC ships it as r/o, but various tools like grub-install do not remount on their own, so they fail strangely. It could be fixed to have userspace mount it, but those things require coordination. Remounting is also a race-y condition for various tools to engage in on their own, for obvious reasons. It also does not change the fact those EFI variables are still exposed as writable once mounted r/w, so even closing the race condition, your system can still be bricked due to a bug. The fix for this in the kernel was to block writes to non-standard UEFI options in efivarfs making them immutable, which prevents accidentally nuking them. This was the actual source of the 'bricking' in the original bug. This is a low-cost fix inside the kernel, which already has to deal with hostile hardware in a million other ways and sanitize various other things to stop all kinds of hardware from crapping itself, just like this. It is also relatively easy for distributions to backport, does not require changing mount semantics for systemd, does not break existing UEFI userspace tools (which would take time to coordinate, and will not manipulate non-standard variables anyway), and stops people from bricking themselves. Logistically, the kernel is really the best and most low-cost place to fix such an issue for everyone, regardless of mount policies on efivarfs in the init system -- in a way that is actually safe for everyone. It would have taken the same time, or more time, to fix it badly (e.g. break userspace tools and require userspace remounts) as fixing it this way. You could level better complaints at UEFI or efivarfs or systemd in general than this one, all things considered... > (I'm not the one who knows best, on this topic) I like how people somehow breathlessly say "systemd developers prove they don't know shit, of course its their fault!!!" and then immediately follow it up with a bunch of fairly basic questions and just admit "oh by the way i don't know what i'm talking about, can anyone tell me otherwise???" systemd annoys me sometimes and I don't like some of its design decisions, but by far its worst "feature" is it causes people who are very unsure of what they are talking about to suddenly become experts about it.
- tmzt 9y ago
  Could you take a mtools-like approach and not remount it at all, just map it and write from userspace?
  - mjg59 9y ago
    Not with the interface that exists now, no. And we wouldn't really want to leave it up to userspace anyway - there are various firmware-based issues that we want to work around in kernel, and relying on userspace to adopt policy there is unlikely to end well.