> I personally don't like. mounting efivars rw is akin to mounting boot rw by default. No, it's not the same. Mounting `/boot` rw by default does not put your

> I personally don't like. mounting efivars rw is akin to mounting boot rw by default. No, it's not the same. Mounting `/boot` rw by default does not put your system in the danger of getting damaged beyond repair. If you hose the boot partition you can always start a recovery system (live Linux or similar) to repair the damage.f But if deleting efivars renders a system inoperable on a firmware level you're essentially SOL, save for rewriting the contents of the system firmware flash using an external programmer and a clean image. That is an absolutely inacceptable situation. The year is 2016 and hosing a firmware by writing malformed values into the firmware API is, simply put, a software vulnerability that allows to permanently DoS a system. As such this is a security issue that must be fixed at where the security issue happens. And in case of efivars the issue is that certain input is not properly validated and/or sanitized. If a system firmware can not properly start with certain variables being unset or removed or set to invalid valued, its should be a implementation requirement to validate input on such variables before executing the change. > Defaulting to rw efivars is, excuse the language stupid. It probably it. But it's not the responsibility of the OS to sanitize values that are not intended for being used by the OS. efivars are intended to be used by (U)EFI and hence it's the (U)EFI implementation's task to properly sanitize access to them. Essentially we're talking Bobby Tables here, just with a different API.