Ce sont les traductions de deux articles que James Bottomley a repris sur son blog. Le premier message a été publié le 1er février et s'intitule "LCA2013 et restructuration du démarrage sécurisé"
Je n'ai pas donné de nouvelles depuis un certain temps, il est donc temps de faire le point sur le chargeur de démarrage sécurisé de la Linux Foundation (d'autant plus qu'il a été présenté à LCA2013). ( Lien vers les diapositives )
Le problème principal est que GregKH (Greg Kroah-Hartman, développeur du noyau) a découvert début décembre que le Pre-BootLoader proposé ne fonctionnait pas, dans sa forme actuelle, avec Gummiboot. Ce constat était décourageant car il signifiait que le projet ne remplissait pas la mission de la Linux Foundation, qui est de permettre l'utilisation de tous les chargeurs d'amorçage. Après investigation, la raison s'est avérée simple : Gummiboot a été créé pour démontrer qu'il était possible de concevoir un chargeur d'amorçage léger et simple, tirant parti de tous les services disponibles sur la plateforme UEFI, au lieu d'être un chargeur de liens volumineux comme GRUB. Malheureusement, cela implique qu'il démarre les noyaux via la fonction BootServices->LoadImage(), ce qui signifie que le noyau à démarrer doit passer par les vérifications de démarrage sécurisé de la plateforme UEFI. À l'origine, le Pre-BootLoader, tout comme shim (le chargeur d'amorçage de Mathew Garrett), avait été conçu pour utiliser le chargement de liens PE/Coff afin de contourner ces vérifications. Malheureusement, cela signifie que tout ce qui est exécuté par le Pre-BootLoader doit également utiliser le chargement de liens pour contourner les contrôles de démarrage sécurisé sur tout ce qu'il souhaite charger, et par conséquent Gummiboot, qui n'est délibérément pas un chargeur de liens, ne fonctionnera pas dans ce système.
J'ai donc dû restructurer et réécrire: le problème allait maintenant de "comment créer un chargeur de lien signé par Microsoft qui obéit à leurs politiques" à "comment permettre à tous les enfants du chargeur de démarrage d'utiliser la fonction BootServices-> LoadImage () de moyen d'obéir à leurs politiques. Heureusement, il existe un moyen d'intercepter l'infrastructure de signature de la plate-forme UEFI en installant votre propre protocole de sécurité d'architecture. Malheureusement, la spécification d'initialisation de la plate-forme ne fait pas partie de la spécification UEFI, mais heureusement, elle est implémentée par tous les systèmes Windows 8 que vous pouvez trouver. La nouvelle architecture intercepte ce protocole et ajoute son propre contrôle de sécurité. Cependant, il y a un deuxième problème: alors que nous sommes dans le callback du protocole de sécurité de l'architecture, nous ne possédons pas forcément l'écran du système UEFI, ce qui rend totalement impossible de faire un test utilisateur pour autoriser l'exécution du binaire. Heureusement, il existe un moyen non interactif de le faire, à savoir le mécanisme SUSE Machine Owner Key (MOK). Par conséquent, le Linux Foundation Pre-BootLoader a maintenant évolué pour utiliser des variables MOK standard pour stocker les hachages binaires autorisés.
Le résultat de tout cela est que le Pre-BootLoader peut maintenant être utilisé avec Gummiboot (comme cela a été fait dans la démo de LCA2013). Pour démarrer, vous devez ajouter 2 hachages: un pour le Gummiboot lui-même et l'autre pour le noyau que vous souhaitez démarrer, mais c'est en fait une bonne chose car maintenant vous avez une seule politique de sécurité contrôlant toute la séquence de démarrage. Le Gummiboot lui-même a également été corrigé pour reconnaître un crash dû au démarrage sécurisé et affiche un message vous indiquant quel hachage enregistrer.
Je ferai un article séparé expliquant le fonctionnement de la nouvelle architecture, mais j'ai pensé qu'il serait préférable d'expliquer ce qui s'est passé le mois dernier.
Et ce deuxième message qu'il a fait hier et s'appelle "Lancement du système de démarrage sécurisé Linux Foundation"
Comme promis, voici le système de démarrage sécurisé Linux Foundation. Il nous a en fait été publié par Microsoft le 6 février, mais avec les voyages, les conférences et les réunions, je n'ai pas eu le temps de tout valider jusqu'à aujourd'hui. Les fichiers sont:
PréLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Créez également une image mini-USB amorçable; (Vous devez l'installer sur l'USB en utilisant dd; l'image a des partitions GPT, donc elle utilise tout le disque). Il a un shell EFI où le noyau devrait être et utilise gummiboot pour le charger. Vous pouvez le trouver ici (md5sum 7971231d133e41dd667a184c255b599f).Pour utiliser l'image mini-USB, vous devez entrer les hachages pour le loader.efi (dans le dossier \ EFI \ BOOT) et le shell.efi (dans le dossier racine). Il comprend également une copie de KeyTool.efi, vous devez entrer le hachage à exécuter.
Qu'est-il arrivé à KeyTool.efi? Il allait à l'origine faire partie de notre kit signé. Cependant, lors des tests, Microsoft a découvert qu'en raison d'un bogue dans l'une des plates-formes UEFI, il pouvait être utilisé pour supprimer la clé de plate-forme par programme, ce qui ruinerait le système de sécurité UEFI. Jusqu'à ce que nous puissions résoudre cela (nous avons le fournisseur privé dans la boucle), ils ont refusé de signer le KeyTool.efi bien que vous puissiez l'autoriser en ajoutant des variables MOK si vous souhaitez l'exécuter.
Faites-moi savoir comment cela se passe, car je suis intéressé à recueillir des commentaires sur ce qui fonctionne et ce qui ne fonctionne pas. En particulier, je crains que le remplacement du protocole de sécurité ne fonctionne pas sur certaines plates-formes, donc je veux particulièrement savoir si cela ne fonctionne pas pour elles.
Fuentes:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Décidez si c'est une bonne ou une mauvaise nouvelle.