openSUSE:UEFI
|
Cette page n'est pas encore traduite (ou pas complètement) Cet article a besoin d'être traduit. Merci de participer au travail si vous en avez le temps et la compétence. |
Sommaire
À propos de UEFI
Introduction au standard
L' interface micro-logicielle extensible unifiée – UEFI Unified Extensible Firmware Interface (en) est une nouvelle norme industrielle qui spécifie les différentes interfaces qu'un système doit offrir dans un environnement pre-boot. UEFI prend le contrôle de la machine après qu'elle est sous tension et que le système est complètement chargé. UEFI joue le rôle d'interface entre les ressources présentées par la machine et le système d'exploitation.
En d'autres termes, UEFI remplace et étend l'ancestral microcode appelé Système d'entrées sorites de base – BIOS Basic Input Output System (en).
UEFI n'est pas quelque chose de nouveau. Intel travaille sur UEFI depuis le milieu des années 90, des intégrateurs tels que HP ou Apple fournissaient déjà des machines EFI depuis bien longtemps. Mais, ce n'est que depuis que Microsoft a sorti Windows 8 qu'UEFI est devenu le moyen exigé pour démarrer les nouvelles machines certifiées.
La spécification UEFI (http://www.uefi.org/specs/) est un très gros document qui décrit toutes les interfaces, variables et structures que le fournisseur du micro-code doit prévoir et qui sont accessibles au système d'exploitation. La bonne nouvelle est que Linux est capable de prendre en charge EFI au démarrage depuis 2000 grâce à GRUB ou à elilo. En fait, openSUSE 12.2 prenait déjà en charge l'UEFI et les versions suivantes d'openSUSE 12.3 assuraient une prise en charge expérimentale de l'extension Secure Boot.
Secure Boot est une extension d'UEFI. L'un des points clé d'UEFI est qu'il est extensible. UEFI dispose d'une machine virtuelle interne qui est indépendante de l'architecture de la machine qu'il utilise. La norme accepte des fichiers binaires spéciaux compilés pour cette machine virtuelle(binaires EFI) qui peuvent s'exécuter dans l'environnement. Ces binaires peuvent être des pilotes de périphérique, des applications ou des extensions de la norme UEFI. UEFI, d'un certain point de vue, est comme un petit système d'exploitation qui s'exécute lorsque la machine est sous énergie et dont la tâche principale est de rechercher et de charger un autre système d'exploitation.
Comment savoir si vous disposez d'une machine UEFI ? Normalement, vérifiez la configuration du micro-code en pressant la touche F1 — ou la touche ESC selon la machine — pendant le tout début de la phase de démarrage. En parcourant les menus présentés, vous pourrez découvrir que la machine peut fonctionner en mode traditionnel — Legacy Mode — et en mode hybride, mode dans lequel le mode finalement choisi sera déterminé en fonction du système d'exploitation à charger.
Si votre machine ne prend pas en charge l'UEFI et que vous voulez tester cette nouvelle technologie avec openSUSE, vous pouvez avoir recours à QEMU et la mise en œuvre de référence d'UEFI par Intel : UEFI and Secure Boot with QEMU.
GPT
UEFI modifie plus que le micro-code, les appels systèmes et les interfaces. Il propose aussi un nouveau style de partitionnement du disque dur. La table de partitionnement GUID – GPT GUID Partition Table (en) – dans laquelle les partitions sont identifiées par leur identifiant unique global – GUID Globally Unique Identifier (en) – est appelée à remplacer le solution traditionnelle de l' enregistrement maître de démarrage – MBR Master Boot Record (en).
Le MBR fait montre de quelques limitations importantes comme le nombre de partitions primaires ou logiques possibles et comme la taille de ces partitions. GPT résout ces problèmes en permettant d'avoir un nombre arbitraire de partitions et un espace disque adressable de 2^64 octets (c.-à-d. 1,8 exabyte ou 1800 petabytes). C'est pourquoi, si vous avez des disques volumineux, c'est le genre de table de partitionnement qu'il vous faut. Une autre différence essentielle, c'est que GPT référence chacune des partitions grâce à un identificateur unique (UUID) se préservant ainsi des risques de doublon dans leur identification.
Lorsque YaST détecte que la machine est en mode EFI, il crée une GPT lors d'une installation initiale. Dès lors que les partitions GPT sont en place, l'ancien outil fdisk n'est plus capable de créer, enlever ou éditer les partitions. Le nouvel outil s'appelle gdisk et se trouve dans le paquet gptdisk. L'interface est identique à celle que nous avions dans fdisk.
Dans certaines circonstances, lorsque vous voulez vous faire la main avec les différents modes, ou si avez besoin de supprimer le formatage GPT de votre disque dur. Vous pouvez le faire avec YaST2. Pour cela, lancez le Partitionneur — il est par défaut en mode expert —, sélectionnez le disque dur concerné sda p. ex., et dans la liste qui se déroule par un clic sur le bouton Expert…, choisissez Créer une nouvelle table de partition.
Ceci remplacera la table de partitionnement en fonction du système sur lequel vous vous trouvez.
La partition EFI System
La partition Système EFI – ESP EFI System Partition (en) – est une partition où UEFI s'attend à trouver les programmes EFI utilisables pour démarrer n'importe quel système d'exploitation présent sur le disque. Il y trouve aussi quelques pilotes de périphériques utilisés au moment du démarrage ainsi que d'autres outils qu'il faut exécuter avant de démarrer le système d'exploitation.
Cette partition utilise un système de fichiers FAT et peut être créée par YaST lors d'une installation sur un disque vide — ou qui ne la contient pas— ou réutilisée si la machine est multi-boot et qu'elle existe déjà. Cela veut dire que si une version moderne de Windows est déjà installée, YaST2 détecte la partition ESP, y place le nouveau chargeur de démarrage EFI utilisable pour démarrer openSUSE et monte cette partition sur le point de montage /boot/efi.
Par défaut, le micro-code recherche l'extension /EFI/BOOT/bootx64.efi qu'il doit charger en mémoire et dont l'exécution procède au chargement du système d'exploitation. Sur les machines Windows, cette extension est dans /EFI/Microsoft/Boot/BCD.efi. Pour openSUSE, elle se trouve dans /EFI/opensuse/grubx64.efi — ou dans shim.efi si le démarrage sécurisé – Secure Boot – est activé.
Le gestionnaire de démarrage
En vue de sélectionner l'extension qu'il faut charger et exécuter pour charger le système d'exploitation choisi, EFI fournit à l'utilisateur un gestionnaire de démarrage intégré. Le système d'exploitation est lui-même responsable de la création d'une nouvelle entrée le concernant. L'utilisateur peut lancer ce gestionnaire et lister toutes les systèmes à démarrer au tout début du processus de démarrage en pressant — généralement — la touche F9 ou F12. Il peut aussi utiliser le efibootmgr pour interroger les entrées et les éditer. Par exemple, pour lister les entrées courantes, il peut exécuter la commande :
BooCurrent: 0006 BootOrder: 0006,0005,0000,0001,0002,0003,0004 Boot000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0) Boot001* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ATAPI(60441d0,0) Boot002* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ATAPI(60441d0,1) Boot003* EFI Hard Drive ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0) Boot004* EFI Internal Shell MM(b,3fa9e000,3ffbdfff) Boot005* opensuse HD(1,800,4e000,F43c4206-073e-4e81-8940-fec01a69e79b) File(\EFI\opensuse\grubx64.efi) Boot005* opensuse-secureboot HD(1,800,4e000,F43c4206-073e-4e81-8940-fec01a69e79b) File(\EFI\opensuse\shim.efi)
Dans la sortie de la commande précédente, nous pouvons voir qu'openSUSE a créé deux entrées différentes pour démarrer. L'une est utilisée lorsque nous sommes en mode sécurisé — Secure Boot — et l'autre quand ce n'est pas le cas.
Si pour une raison ou une autre, nous perdons l'une des entrées, nous pouvons la recréer en utilisant la commande efibootmgr. Par exemple, pour recréer l'entrée opensuse nous pouvons faire :
Les variables EFI
La norme UEFI spécifie un jeu de variables qui sont conservées dans une partie non volatile du micro-code. Ces variables sont utilisées pour stocker de l'information et pour contrôler le comportement du système UEFI. Lorsque nous créons une nouvelle entrée dans le gestionnaire de démarrage, ou lorsque nous activons ou désactivons le Secure Boot, pour ne prendre que ces deux exemples, nous altérons le contenu de ces variables. Nous pouvons interroger ces variables et y accéder directement depuis openSUSE via Sysfs. Sysfs est un système de fichiers virtuels fournit par le noyau pour exporter des informations internes vers l'espace utilisateur. Nous pouvons accéder à ces variables dans /sys/firmware/efi/vars/. Ainsi, par exemple, la dernière entrée du gestionnaire de démarrage peut être interrogée avec :
Secure Boot
Contexte
Le démarrage sécurisé UEFI – UEFI Secure Boot (en) – est une méthode pour contrôler quels binaires peuvent être exécutés pour assurer le démarrage d'un système. Le micro-code n'exécute que les chargeurs de démarrage qui portent la signature cryptographique d'entités reconnues. Dans le cadre de Secure Boot X.509 les certificats sont le moyen d'identifier une entité.
Aujourd'hui, la plupart des ordinateurs dont le Secure Boot est activé sont fournis avec Microsoft Windows. C'est pourquoi le micro-code ne connaît que Microsoft en tant qu'entité reconnue pour signer les gestionnaires de démarrage. Pour assurer le démarrage d'openSUSE sans avoir à reconfigurer la liste des entités reconnues ou à désactiver le Secure Boot, le chargeur de démarrage d'openSUSE doit être signé par Microsoft.
Mise en œuvre dans openSUSE 12.3
Le chargeur de démarrage utilisé par défaut par openSUSE 12.3 sur les systèmes UEFI est grub2. Lorsque le Secure Boot est activé, un chargeur additionnel appelé shim est utilisé également. Dans ce mode, au lieu d'appeler directement grub2, le micro-code commence par charger shim. shim est signé par Microsoft afin d'être accepté par le micro-code. Grub2 est signé par openSUSE et ce certificat est reconnu et accepté par shim. Les noyaux Linux sont signés par openSUSE dont la signature est reconnue et acceptée par grub2. Une fois que grub2 a chargé le noyau Linux nous sommes en dehors du champ du Secure Boot. Le noyau Linux utilisé par openSUSE n'impose pas de restrictions additionnelles.
Afin de permettre l'utilisation de chargeurs de démarrage et de noyaux personnalisés, shim permet d'importer des signatures personnalisées. Le programme MokManager est utilisé à cette fin. Lorsqu'on demande à shim de charger un binaire dont il ne reconnaît pas la signature, il fait appel à MokManager qui permet d'importer des certificats dans la base de données des entités reconnues.
Comment activer ou désactiver le Secure Boot
Le Secure Boot dans openSUSE 12.3 est en phase d'expérimentation. L'installateur YaST ne sait pas détecter automatiquement si le Secure Boot est activé ou pas. Pendant l'installation, il offre la possibilité de l'activer manuellement. L'activation de cette option est requise pour que shim puisse être installé. Pour activer ou désactiver le Secure Boot sur un système déjà installé, le module chargeur de démarrage de YaST peut être utilisé.
Comment savoir si le Secure Boot est activé
Pour savoir si le Secure Boot est activé dans le micro-code, saisissez la commande suivante en tant que super utilisateur :
Le Secure Boot est activé si la commande retourne 1. Quelques micro-codes sont réputés cassés et retournent 0 même lorsque le Secure Boot est activé.
Démarrer un noyau personnalisé
Secure boot ne vous interdit pas d'utiliser le noyau que vous avez compilé vous-même. Il vous faut juste le signer avec votre propre certificat et faire en sorte que le micro-code ou MOKreconnaisse ce certificat.
- créez un certificat et une clé X.509 pour la signature : user $ openssl req -new -x509 -newkey rsa:2048 -sha256 -keyout key.asc -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
- empaquetez la clé et le certificat en tant que structure PKCS#12: user $ openssl pkcs12 -export -inkey key.asc -in cert.pem -name kernel_cert -out cert.p12
- générez la base de données NSS utilisée par pesign:user $ certutil -d . -N
- importez la clé et le certificat conteun dans la structure PKCS#12 dans la base de données NSS :user $ pk12util -d . -i cert.p12
- signez le noyau avec la nouvelle signature :user $ pesign -n . -c kernel_cert -i arch/x86/boot/bzImage -o vmlinuz.signed -s
- listez les signatures dont bénéficie ce noyau :user $ pesign -n . -S -i vmlinuz.signed
Arrivé à ce point, you pouvez installer ce noyau dans /boot comme à l'accoutumée. Comme le noyau dispose désormais d'une signature personnalisée, il faut importer le certificat qui a servi à le signer dans le micro-code ou dans MOK.
- convertissez certificat au format DER pour importation dans le micro-code UEFI ou dans MOK : user $ openssl x509 -in cert.pem -outform der -out cert.der
- copiez le certificat dans la partition EFI System (ESP) pour en faciliter l'accès : user $ sudo cp cert.der /boot/efi/
Malheureusement, mokutil est toujours cassé sur openSUSE 12.3 c'est pourquoi il n'y a pas de moyen adapté pour lancer MOK automatiquement. La procédure suivante montre comment le faire à la main :
- Redémarrez.
- Dans le menu de grub pressez la touche c.
- Saisissez la commande (en supposant qu la partition EFI System' s'appelle 'gpt1' sur 'hd0'): user $ chainloader (hd0,gpt1)/EFI/opensuse/MokManager.efiuser $ boot
- Selectionnez "Enregistrer un clé depuis le disque"
- Naviguez vers le fichier cert.der file et pressez la touche Entrée.
- Suivre les instructions pour enregistrer la clé. Normalement cela devrait fait en pressant la touche 0, puis y(ou o selon la langue) pour confirmer.
En alternative, le micro-code peut peut-être fournir un moyen d'ajouter une clé à la base de données.
Démarrer la machine sans les clés fournies par le vendeur
Si le menu du micro-code offre les options pour réinitialiser les clés utilisées par le Secure Boot, vous pouvez installer de nouvelles PK, KEK et db sans les clés de Microsoft. Importez /usr/lib64/efi/shim-opensuse.der dans la base de donnée pour que les noyaux Linux démarrent dans ce cas. Le shim par défaut est signé à la fois par Microsoft et par openSUSE. Quelques versions de micro-code n'acceptent cependant pas la double signature. Dans ce cas, installez /usr/lib64/efi/shim-opensuse.efi qui ne possède que la signature openSUSE en tant que /boot/efi/EFI/opensuse/shim.efi.
Démarrer une machine qui ne prend en charge qu'une seule signature avec les clés fournies par le fabricant
Certains micro-codes ne peuvent rechercher qu'une seule signature dans les images EFI. Ceci fait que shim échoue dans ce cas. Si le micro-code ne fournit pas de moyen pour installer de nouvelles clés, vous devez déshabiller la signature d'openSUSE à la main pour contourner le problème.
- Installez mozilla-nss-tools et pesign root # zypper install mozilla-nss-tools pesign
- Créez une base de données nss temporaire user $
... (suite de la sortie de la commande précédente)
pressez "Entrée" pour ignorer la demande de mot de passe - Déshabiller la signature openSUSE user $ pesign -n certdb/ -r -i /usr/lib64/efi/shim.efi -o shim.efi -u 1
- Remplacez le fichier shim.efi avec le fichier shim.efi nouvellement généré user $ mv shim.efi /boot/efi/EFI/opensuse/shim.efi
- Retirez la base de données temporaire nss' user $
... (suite de la sortie de la commande précédente)
Ces deux étapes doivent être répétées à chaque fois que shim est mis à jour. Ce genre de micro-code devrait avoir tendance à disparaître car la prise en charge des signatures multiples est déjà incluse dans l'amont de edk2 depuis plus d'un an, mais il peut encore exister sur des machines anciennes.
Glossaire
- PK
- "Platform Key" — clé de plate-forme — fait typiquement référence à un certificat installé sur la machine par le vendeur du matériel. Pour pouvoir modifier la KEK une signature valide de la PK est requise.
- KEK
- Une signature valide de la KEK ("Key Exchange Key") est nécessaire pour mettre à jour la base de données des signatures.
- db
- La base de données des signatures qui contient les certificats, signatures et hachages des binaires des entités reconnues. Seules les binaires qui peuvent être vérifiés en utilisant cette base de données sont exécutés par le micro-code. Une signature valide de la KEK est nécessaire pour mettre à jour cette base de données.
- dbx
- La base de données des signatures interdites. C'est l'opposé de la db, basiquement une liste noire des certificats, signatures et hachages. Si un binaire correspond à l'une des ces entrées il ne peut être exécuté. Une signature valide de la KEK est nécessaire pour mettre à jour cette base de données.
- MOK
- Machine Owner Keys — Clés du propriétaire de la machine. Une base de données additionnelle des certificats ou hachages utilisés par MokManager. MokManager peut être utilisé interactivement par l'utilisateur pendant le démarrage pour mettre MOK à jour.