&gt; I personally don&#x27;t like. mounting efivars rw is akin to mounting boot rw by default.<p>No, it&#x27;s not the same. Mounting `&#x2F;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<p>But if deleting efivars renders a system inoperable on a firmware level you&#x27;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&#x2F;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.<p>&gt; Defaulting to rw efivars is, excuse the language stupid.<p>It probably it. But it&#x27;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&#x27;s the (U)EFI implementation&#x27;s task to properly sanitize access to them.<p>Essentially we&#x27;re talking Bobby Tables here, just with a different API.