./5948 > La spec UEFI ne dit pas grand chose à ce sujet. Elle dit que si les variables de boot ne sont pas initialisées (variables nommées explicitement dans la spec. et ça ne cause évidemment pas des autres) alors le système doit avoir un comportement de boot bien spécifique. (cf. la spec pour le processus exact)
Pour le reste, toutes les variables UEFI sont séparées en "namespaces" (façon de parler: c'est des GUID) et la spec t'interdit explicitement de foutre quoi que ce soit dans le namespace global qui ne soit pas officiellement spécifié.
Implicitement, t'es sensé comprendre que t'as rien à foutre à toucher aux namespaces dont tu ignores "à priori" l'existence (t'as le droit d'énumérer les variables, mais tu peux pas savoir à quoi elles servent sans doc ou reverse-engineering), puisque c'est obligatoirement des variables que t'es pas sensé toucher comme ça. C'est pas tes variables, tu dois pas y toucher. (Mais rien ne l'interdit explicitement)
Maintenant, dans tous ces cas, c'est totalement évident que tu n'as pas la garantie que le moindre fabricant respecte la norme à la lettre. (Même Apple est très très libérale dans son implémentation de la chose, et expose des comportements de boot incohérents. Par contre, le système doit franchement pas être facile à bricker vu le peu de latitude qu'il te laisse.)
Toujours est-il que si vous regardez un tant soit peu la tronche de ce que j'ose à peine qualifier d'API:
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-firmware-efi-vars (data, raw_var, new_var, del_var) ça n'a vraiment absolument rien à foutre dans un système de fichiers, mais bon

(Puis en réalité ça apparait assez clair qu'il suffisait de pas exposer la fonctionnalité unlink sur les inode du fs foireux, comme ça il aurait ressemblé encore moins à un fs, et l'honneur aurait été sauf. Vu le reste de l'implémentation, ça aurait très bien fonctionné ainsi… (Hint: suffisait d'utiliser/fournir del_var exclusivement))
Maintenant, ouais on peut très bien être d'accord que le fabricant a fait de la merde (en même temps t'était pas sensé regardé), que le noyau a fait de la merde (l'était pas sensé exposer cette API comme ça, l'était pas sensé la rendre si facile d'accès, mais c'est pas son boulot de faire la sécurité sur les variables, par contre !), et que systemd a fait de la merde (l'était pas sensé toucher à un truc si critique de manière non réfléchie).
Enfin quand même :/