> goes against the Unix philosophy of "root can do anything."
I don't think that's a useful perspective here. This is not a feature - nothing should ever want to permanently brick a motherboard, there's no use case for that. There's no benefit to allowing root to do this. The OS is supposed to abstract the hardware in a way that it can be safely operated.
I think you are mistaken about some of the details here. We are talking about root being able to write to efivarfs, which is needed for some valid reasons. Unfortunately, there are firmware implementations out there that don't handle some variables being overridden/wiped, and it bricks the system. So, the problem is bad firmware, exacerbated by the choice to represent EFI variable as a filesystem and what happens when you do a "rm -rf /" (in the simplest example). So, in my eyes, root should be able to write to efivarfs when needed, but we should mitigate this problem in some way so it's hard to accidentally brick your system by making it a little harder (but not impossible) for root to write to this filesystem. It's not possible to allow root to write to EFI while still ensuring that it can't brick the machine, because the responsibility for that capability lies with the firmware developers.
My understanding is that the amount of software that wants/needs to write to efivarfs is fairly small[1] compared to the amount of software that is normally run with root privileges.
The fact is that 'rm -rf /' is a common mistake, both at the command line (i.e. manually typing) and in scripts that don't adequately protect against things like missing variables. E.g.:
MY_DIR=
rm -rf "$MY_DIR/"
The fact that this could brick a system is a big deal. Pushing blame around doesn't do anybody any good.
[1] I realize that boot loaders like grub are everywhere and probably need to write to efivarfs, but that's still a data point of 1. Would it be that difficult for grub and it's related scripts to upgrade to remount the filesystem readwrite when it needs to perform an operation? I'm sure it's only been a couple of years since efivarfs functionality was even added to grub.
I understand and agree with all of this, I'm just not sure how it follows from what I wrote. The problem has a fix scheduled (what this submission is about), and in a fairly short period of time (~30 days for a fairly esoteric[1] bug).
To my mind there are two places to fix this, in the kernel for a real mitigation technique that helps "solve" the problem, and in the distros for quick fixes and hacks, or backports of the kernel fix, as necessary. Systemd pushing a fix of their own 1) only affects distros using systemd, while this problem affects all recent distros that use efivarfs), 2) probably won't get picked up by distros immediately excapt as a backported fix anyway, as I doubt most of them push new versions of something as integral as systemd every time a new version is out, at least not with a lot of testing, and 3) would not have been a good fix, and would have required the utilities that still needed access to actually remount a filesystem.
1: Triggering this problem is not as easy as what you (and I) wrote in most instances, as / has special consideration in rm, and generally requires the "--no-preserve-root" flag.
I don't think that's a useful perspective here. This is not a feature - nothing should ever want to permanently brick a motherboard, there's no use case for that. There's no benefit to allowing root to do this. The OS is supposed to abstract the hardware in a way that it can be safely operated.