Deux nouvelles concernant le pré-bootloader

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 suis resté silencieux pendant un moment, il est donc temps de faire le point sur ce qui se passe avec le chargeur de démarrage sécurisé de la Linux Foundation (surtout qu'il a été présenté à LCA2013). (Lien vers les diapositives)

L'essence du problème est que GregKH (le développeur du noyau Greg Kroah-Hartman) a découvert début décembre que le Pre-BootLoader proposé ne fonctionnerait pas dans sa forme actuelle avec Gummiboot. C'était quelque peu intimidant car cela signifiait qu'il ne remplissait pas la mission de la Linux Foundation d'activer tous les chargeurs de démarrage. Dans la recherche, la raison était simple: Gummiboot a été créé pour démontrer que vous pouviez créer un chargeur de démarrage petit et simple qui tirerait parti de tous les services disponibles sur la plate-forme UEFI au lieu d'être un chargeur de liens massif comme GRUB. Malheureusement, cela signifie que vous démarrez les noyaux en utilisant la fonction BootServices-> LoadImage (), ce qui signifie que le noyau à démarrer doit passer par les vérifications de démarrage sécurisé sur la plate-forme UEFI. À l'origine, le Pre-BootLoader, comme cale (Le chargeur de démarrage de Mathew Garrett), a été écrit pour utiliser le chargement de lien PE / Coff pour vaincre les vérifications de démarrage sécurisées. Malheureusement, cela signifie que quelque chose exécuté par le Pre-BootLoader doit également utiliser le chargement de lien pour battre les vérifications de démarrage sécurisé sur tout ce qu'il veut charger et par conséquent Gummiboot, qui n'est délibérément pas un chargeur de lien, ne fonctionnera pas sous ce schéma.

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.