I can see the point that you shouldn't make otherwise-undesirable OS changes to accommodate incompetent hardware designers. The thing is, I'm not convinced that it this is undesirable: mounting efivars read-only by default seems like a completely reasonable thing to do, even absent this particular hardware issue. BIOS setting are important and rarely need to be changed, and anything that doesn't have the privileges to unlock efivars probably shouldn't be messing with it anyway.
> mounting efivars read-only by default seems like a completely reasonable thing to do, even absent this particular hardware issue.
It's perfectly reasonable to ro mount efivars. But doing so must not be the workaround to fix an security issue (and yes, this is a security issue) in (certain implementations of)(U)EFI. Just to make clear why this is an security issue: Security rests of three pillars:
- availability
- confidentiality
- authenticity
Rendering a system unusable (DoS-ing it) it an attack on availability. And speaking of security, if the goal is sabotage and causing large financial damages, then being able to permanently brick a system in case of a privilege escalation (there's nothing stopping UID=0 from remounting rw efivars) is pretty bad; and no, the implemented fixes in the efivars kernel code don't help, because an attacker can still mount a custom kernel module which will talk to the respective efivars code directly circumventing sanity checks (or directly talk to (U)EFI without using the efivars code).
