Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI

This is a case of a leaky abstraction (https://en.wikipedia.org/wiki/Leaky_abstraction). The "everything is a file" philosophy is the real problem here.

Specifically, the way a mental model of a hierarchy is broken by mounting a higher-order ressource (UEFI variables) as a subordinate of a file system that is itself a subordinate of the OS.

UEFI vars are just hardware resources. Mapping them as a file system object is just unnatural and, yes, stupid.

Trying to use a permission model ("only root can do it") overlooks the real problem: The user do not expect higher order objects to be mapped as subordinates of the file system.

When you delete from the file system, you expect objects to be deleted from the disk - not UEFI variables to be altered or deleted! And because the user does not expect such behavior, there's a good chance she/he will override warnings and go ahead with the operation expecting only file system objects to be affected.

This is "everything is a file" taken a bridge too far.

Good lord, presenting distinct data points with content and a name as a filesystem mount is a "problem".

The EFIVars table is stored in mainboard flash as... file(s). Probably only one, since the firmware isn't going to be using a filesystem.

But it is still a map of key-value pairs. That maps perfectly fine to a filesystem.

Nothing about the "brick your laptop with rm -rf /" is the fault of any free software component or philosophy. By the specification of UEFI itself the efivar table is for transient data storage between the OS and the firmware. It is supposed to be mutable, removable, you can do whatever you want to it as an OS and the firmware can do whatever it wants as well and neithers behavior should stop the world.

All this was is a demonstration of why proprietary firmware is bad, and that again the free software community needs to work around broken proprietary crap that cannot obey its own design documents.

If you want to soapbox about how everything would be easier if we had to link a library and access all OS level data through some 50k command API instead of through files... I'm not sure you are going to actually find an instance where people are improperly treating data as files, because almost anything can be treated as a file. You can implement it poorly, but if it is data and it has organization you can put it in a filesystem.