Proposer de remonter en ro les efivars peut être un quick & dirty fix pour ce problème, mais ne le résout pas !
À un moment ou un autre, un programme de mise à jour du bootloader aura besoin d'écrire dedans (ben oui, on ne montes pas ces efivars en rw pour le plaisir) et il faudra les remonter en rw à ce moment là et même si le code de se programme se charge lui-même de passer les efivars en rw pour limiter le temps d’exposition on n’est pas à l’abri d'un bug de ce programme lui-même qui fout le boxon lors de l'écriture.
Je parle là de bootloaders genre systemd-bootd(ex. gummyboot), grub, syslinux, rEFIt... Mais un logiciel de restauration système (ou d'installation en masse automatisé etc. etc.) sous Windows ou même DOS peut être amené à manipuler ces variables, et y causer des dégâts.
Bref idéalement c'est aux CM de s'assurer que l'UEFI reste dans une configuration utilisable, mais comme suggéré plus haut, rien ne s'oppose à un mettre un gestionnaire de "quirk" dans le kernel pour protéger un UEFI pourri, ça existe déjà pour d'autres composants.
# ro c'est bien gentil, mais
Posté par Tonton Benoit . En réponse au journal rm -rf tue votre bios UEFI. Évalué à 6. Dernière modification le 02 février 2016 à 21:55.
Proposer de remonter en ro les efivars peut être un quick & dirty fix pour ce problème, mais ne le résout pas !
À un moment ou un autre, un programme de mise à jour du bootloader aura besoin d'écrire dedans (ben oui, on ne montes pas ces efivars en rw pour le plaisir) et il faudra les remonter en rw à ce moment là et même si le code de se programme se charge lui-même de passer les efivars en rw pour limiter le temps d’exposition on n’est pas à l’abri d'un bug de ce programme lui-même qui fout le boxon lors de l'écriture.
Je parle là de bootloaders genre systemd-bootd(ex. gummyboot), grub, syslinux, rEFIt... Mais un logiciel de restauration système (ou d'installation en masse automatisé etc. etc.) sous Windows ou même DOS peut être amené à manipuler ces variables, et y causer des dégâts.
Bref idéalement c'est aux CM de s'assurer que l'UEFI reste dans une configuration utilisable, mais comme suggéré plus haut, rien ne s'oppose à un mettre un gestionnaire de "quirk" dans le kernel pour protéger un UEFI pourri, ça existe déjà pour d'autres composants.