This is in reference to the issue a few years ago where it was easy to wipe EFI vars via /sys, which would happen if you rm -rf / .[1] Wiping the EFI vars would brick your system.

[1]: https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

You used to be able (maybe still are?) to "rm" the files on a mounted efivarfs. See the relevant systemd issue ([1]).

[1] https://github.com/systemd/systemd/issues/2402

well windows can get write access to these aswell. (just not by using rm or any other tool to remove files by default). I think this is a big difference and should probably be addressed. make /sys read-only and allow to write them differently with a interface where I need to call THIS_METHOD_CAN_BREAK_A_SYSTEM_IF_USED_INCORRECT_WRITE_SYS() command. but well, systemd guys will/won't do that.

It wasn't a systemd thing. The people who relate the tale as if it were a systemd thing or something that the systemd people did are ill-informed. Much as in the case of the headlined bug at hand, it was entirely a kernel thing. This was even stated outright at the time by the creator of that particular kernel mechanism.

To learn the real story, go and read https://news.ycombinator.com/item?id=11152880 where you will find Matthew Garrett xyrself participating in the discussion.

Not any more. Non-spec variables are initially immutable, so can't be removed until you toggle that.

And which you could do a few years back by rm-ing files from a virtual device that mapped to BIOS configuration.