6 ms·

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 certain

by 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.
- gens 9y ago
  It's all during boot or shutdown... >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???" I like how stating to a bunch of people who don't know anything about you that you are not all knowledgeable, and asking questions to better inform yourself and to put things into perspective (for everyone involved) is looked at as a weakness/sign of ignorance. For the record i know a lot about how computers, and linux, work. From the basic transistors and gates, to high level programming constructs. It's just that this particular topic does not interest me, nor will knowing it help me in any way, shape, or form in my life. As for "systemd developers prove they don't know shit, of course its their fault!!!". It is. Shit has happened and their response was "Not my problem"... numerous times. If the people that declared themselves "the grand arch-mages of.. everything", and are forcing their "arch-mag-iness" as "the standard of all and forever", then they are responsible for the problems of "everything". As they say "with great power comes great force times distance over time", or something like that.
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.

by gens 9y ago

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.

gens 9y ago
It's all during boot or shutdown... >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???" I like how stating to a bunch of people who don't know anything about you that you are not all knowledgeable, and asking questions to better inform yourself and to put things into perspective (for everyone involved) is looked at as a weakness/sign of ignorance. For the record i know a lot about how computers, and linux, work. From the basic transistors and gates, to high level programming constructs. It's just that this particular topic does not interest me, nor will knowing it help me in any way, shape, or form in my life. As for "systemd developers prove they don't know shit, of course its their fault!!!". It is. Shit has happened and their response was "Not my problem"... numerous times. If the people that declared themselves "the grand arch-mages of.. everything", and are forcing their "arch-mag-iness" as "the standard of all and forever", then they are responsible for the problems of "everything". As they say "with great power comes great force times distance over time", or something like that.

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.