It should be mounted rw because existing userspace expects it to be rw.
> It shouldn't be mounted by default.
It should be mounted by default because it's information that's relevant to various pieces of userspace.
> It shouldn't even be a bloody filesystem.
With hindsight, it should absolutely not have been a filesystem. There's very little metadata associated with EFI variables and the convenience of exposing this in a way that can be handled using read and write is huge, but real-world firmware turns out to be fragile enough that this was a mistake. But, in the absence of a time machine, there's very little I can do to fix that now.
Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a firmware partition to be writable. Even if there are any, certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.
As for why userspace couldn't remount it itself - it could. It doesn't. Changing the behaviour of systemd without changing the behaviour of the rest of userspace would result in userspace being broken, and making that kind of incompatible change is annoying - especially when fixing it in the kernel allows us to avoid that breakage.
Best example of why you need to have it RW: if uefi is in fast boot, the only way to actually enter uefi is to boot an OS and have the OS set the uefi variables so that it goes into the firmware screen on next restart. This is (on Linux) done by changing something in that virtual filesystem.
> certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.
You could probably remount it, but that also means that you all the sudden have concurrency problems with that operation. So not really ideal.
The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.