Bricking systems using rm

Posted Feb 12, 2016 19:01 UTC (Fri) by flussence (guest, #85566)
In reply to: Bricking systems using rm by fandingo
Parent article: Bricking systems using rm

> Why represent EFI variables as a file system?

Want to hear a pedantically horrific answer? They're not *a* filesystem.

They're *two*! /sys/firmware/efi/{efivars,vars}/

The latter is a part of sysfs and uses a far more reasonable “echo an ID to one control file to create a var, another to delete one” interface. Given that it existed already, I'm not sure why an end-user-friendly way to scribble over system nvram was added in the first place.

Bricking systems using rm

Posted Feb 12, 2016 19:07 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (2 responses)

Because sysfs can't represent data that's larger than a page, and EFI variables can be (per spec) arbitrarily large.

Bricking systems using rm

Posted Feb 12, 2016 19:48 UTC (Fri) by gregkh (subscriber, #8) [Link] (1 responses)

sysfs can handle files that are larger than a page, just use the binary file interface, which for stuff like this (i.e. firmware), should be just fine.

Bricking systems using rm

Posted Feb 12, 2016 19:58 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Oh, sorry, I was misremembering what the problem was. The existing efivar ABI hardcoded an assumption that variables weren't more than 1K large, including the name as part of the size. At the time we had no reason to think that firmware would turn out to be so fragile around variables, so since we were going to have to implement a new ABI anyway, doing it as a filesystem seemed cleaner. Hindsight, etc.