Comment fonctionne le démarrage sécurisé?
Je joue avec GRUB2, SecureBoot et Kernel Signing et je pense avoir trouvé un bogue possible dans mon Secure Boot, mais je veux d'abord vérifier ma compréhension de ces processus.
Je sais que lorsque le démarrage sécurisé est activé, seuls les fichiers binaires signés avec une clé chargée dans le micrologiciel peuvent être lancés. Tous les chargeurs de démarrage doivent donc être signés. Dans un cas typique, shim et GRUB.
Shim devrait lancer le MoakManager si le démarrage échoue ou si vous avez des clés à importer ou à supprimer et si tout va bien, il devrait alors lancer GRUB qui est le véritable chargeur de démarrage.
Le problème est que je viens de générer une version personnalisée de GRUB avec grub-mkstandalone que j'ai signée avec une nouvelle clé créée avec OpenSSl; une clé que je n'ai pas encore importée dans le firmware, et shim a pu la lancer sans aucun rapport de Secure Boot.
J'ai vérifié les clés avec mokutil --list-enrolled et il ne signalait que le certificat Canonical.
Donc, pour récapituler:
Dans ma partition EFI, j'ai:
- shimx64.efi signé par Canonical, généré avec grub-install
- mon GRUB personnalisé, généré avec grub-mkstandalone, signé avec ma propre clé, que je n'ai pas encore importée, nommé
grubx64.efi.
Au démarrage, SHIM pourrait déjeuner GRUB et GRUB pourrait démarrer Ubuntu avec succès.
Si certains Secure Boot vérifient uniquement le signe du premier chargeur de démarrage et que les autres chargeurs sont responsables de se vérifier eux-mêmes ainsi que des modules qu'ils préchargent et que les utilisateurs chargent, le problème de sécurité est très important.
Je ferai d'autres tests, mais je devrais peut-être ouvrir un ticket de bogue.
Des idées?
Je crois que votre compréhension est correcte, , sauf que shimx64.efi est livré sous forme binaire via un package, non généré localement via grub-install. (grub-install est susceptible de installer shimx64.efi sur l'ESP.) Oh, et c'est MokManager, pas MoakManager.
Avant de déposer un rapport de bogue, vous devez retracer vos étapes et être sûr à 100% que vous démarrez avec votre GRUB compilé localement. Il est facile de placer accidentellement un binaire au mauvais emplacement ou de négliger de lancer efibootmgr pour ajuster l'ordre de démarrage, par exemple. (Vous n'avez pas décrit comment vous installez votre grubx64.efi personnalisé - écrasez-vous le binaire Ubuntu standard ou placez-vous le nouveau binaire ailleurs et enregistrez-le [et une copie de Shim] via efibootmgr? ) Vous voudrez peut-être exécuter Sudo efibootmgr -v pour voir les détails de votre démarrage. Faites attention aux lignes BootOrder et BootCurrent - la première vous indique l'ordre dans lequel les options de démarrage seront testées et la dernière indique l'option utilisée pour démarrer l'ordinateur. Vous aurez besoin de renvoyer les numéros avec les différentes lignes Boot#### décrivant chaque option de démarrage. Si vous avez installé votre propre GRUB distinct du GRUB d’Ubuntu, il est concevable que le microprogramme l’ait contourné en silence à cause d’une erreur de démarrage sécurisé, puis se soit replié sur le stock Ubuntu Shim/GRUB, ce qui expliquerait ce que vous êtes. voyant.
Une autre possibilité est que Secure Boot ne soit pas activé sur votre ordinateur. Vous pouvez vérifier cette possibilité comme suit:
$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
0000000 0016 0000 0001
0000005
Dans cet exemple, la première ligne de sortie (0000000 0016 0000 0001) se termine par un 1. Cela indique que le démarrage sécurisé est actif. S'il se termine par un 0, le démarrage sécurisé est désactivé sur votre ordinateur.
Une autre possibilité est que vous ayez peut-être installé votre clé locale dans la liste de base de données du microprogramme. C'est une tâche difficile, cependant, il est donc peu probable que vous l'ayez accomplie accidentellement et sans vous en rendre compte. (Voir ma page sur le sujet pour des détails sur la manière de le configurer.) Je mentionne cette possibilité principalement pour des raisons de complétude; cela ne me semble pas du tout probable, à moins que vous n'ignoriez une tentative précédente de maîtriser Secure Boot de cette manière.
Si vous voyez un bogue, il se peut que ce soit dans Shim ou dans votre firmware.
Un autre inconvénient est que je ne connais que très bien des outils spécifiques à GRUB, tels que grub-mkstandalone. Comme je maintiens rEFInd, je préfère l’utiliser. Par conséquent, ma connaissance des outils GRUB n’est pas aussi approfondie qu’elle pourrait l’être. Il se peut donc que certains détails essentiels me manquent, car ils sont spécifiques à GRUB.