URL: https://linuxfr.org/news/uefi-a-la-decouverte-du-nouveau-bios Title: UEFI, à la découverte du nouveau BIOS Authors: Pinaraf Date: 2011年10月25日T12:28:07+02:00 Tags: efi, debian, bios, grub et uefi Score: 64 NdM : Cette dépêche est issue d’un journal, merci à son auteur. Qu’il semble loin le temps, béni pour certains, maudits pour d’autres, où il était nécessaire de connaître les [IRQ](http://fr.wikipedia.org/wiki/Interruption_mat%C3%A9rielle) et [DMA](http://fr.wikipedia.org/wiki/Direct_Memory_Access) de sa machine pour l’utiliser, où, loin du _plug’n’play_, le matériel se contentait de laisser l’humain configurer... Puis vint le _plug’n’play_, son compagnon l’[[ACPI]] permettant de lister le matériel et de le configurer magiquement. Mais toujours, au sein de la machine, un petit logiciel, le [BIOS](http://fr.wikipedia.org/wiki/Basic_Input_Output_System). ---- [Journal à l’origine de la dépêche](https://linuxfr.org/users/pied/journaux/uefi-%C3%A0-la-d%C3%A9couverte-du-nouveau-bios%E2%80%A6) ---- # Plongeons‐nous dans les entrailles de nos machines # Le BIOS est, de manière assez surprenante, l’élément probablement à l’origine du succès de l’IBM PC. En effet, le BIOS, l’élément primitif indispensable au démarrage de la machine, a été mis, non pas sur les disques de _boot_, mais en ROM sur la carte mère. Quelques années plus tard, après un peu de rétro‐ingénierie, des fabricants ont pu commencer à vendre des clones de PC compatibles, basés sur une ré‐implémentation du BIOS. Le BIOS est moche, clairement ; très basique, très crade. Mais il faisait son travail, il fournit une abstraction très primitive au matériel. On pouvait presque écrire un OS uniquement en faisant des appels au BIOS, comme DOS. Les appels au BIOS sont très simples : il s’agit tout bêtement d’une série d’interruptions matérielles. À travers l’IRQ 0x10, on peut donner différentes instructions à la carte graphique, via le registre AH : défilement (_scrolling_), changement de mode et des couleurs. L’IRQ 0x13 permet de contrôler les disques. Naissance d’EFI =============== Mais avec l’évolution du matériel, les limites sont apparues : le BIOS utilise un mode 16 bits, ne lui permettant pas d’adresser toute la RAM, l’amorçage par le réseau ou par CD est apparu, l’USB est arrivé. Récemment toutefois, nous avons atteint une limite très difficile à surmonter : la table des partitions gérée par le BIOS ne permet pas d’exploiter des disques de plus de 2 Tio. En parallèle, depuis la fin des années 90, Intel avait développé, en partenariat avec HP, l’architecture Itanium, pour laquelle l’utilisation du BIOS n’était pas envisageable. Ainsi, Intel développa un outil moderne, puissant, flexible, simple et unanimement repris : l’EFI. Bon, OK, en vrai c’est plus compliqué : en 1994, l’[[IEEE]] avait déjà standardisé Open Firmware, une solution multi‐plate‐forme et acceptée pour accomplir une tâche similaire au BIOS. Utilisé sur les machines Sun, Apple, IBM, c’est un outil qui a fait ses preuves et continue à les faire. Mais pour Intel, Open Firmware n’est pas acceptable. Officiellement, c’est parce que l’Open Firmware duplique l’ACPI en fournissant son propre arbre de périphériques. Mais depuis, le projet OLPC a prouvé qu’en fait, c’est possible. Par contre dans EFI, il y a un arbre de périphériques potentiellement différent de celui de l’ACPI (et vous êtes loin de la fin de ce journal, hein). EFI est décrit dans une spécification, contrairement au BIOS, qui n’a jamais eu de telle documentation : 2 210 pages, plus les 800 pages d’ACPI. Mangez la spécification, c’est du bon. Bien sûr, EFI a évolué lui aussi : la norme EFI a cessé d’évoluer et l’UEFI fut créé à partir d’EFI 1.10. UEFI est une évolution d’EFI contrôlée par le _Forum UEFI_ et non plus par Intel. En 2007, la version 2.1 d’UEFI a apporté la cryptographie, l’authentification réseau, la possibilité de construire une interface graphique. Ouais, on parle toujours de _« firmware »_. Voyons un peu comment est construit un EFI =========================================== On a en fait trois couches dans EFI. Au cœur, se trouve le PEI, _Pre‐EFI Initialization_. Responsable de l’initialisation très bas niveau, comme le contrôleur mémoire (truc super‐tordu mine de rien, _cf._ les présentations des auteurs de _coreboot_), il gère à la fois le tout début de l’allumage de la machine, mais aussi la sortie de veille. Une fois qu’il a fait son travail, il laisse la main à la deuxième couche et disparaît. La deuxième couche se nomme DXE, _Driver eXecution Environment_. C’est ce que l’on voit finalement du _firmware_. C’est un élément indépendant du matériel, capable de charger des pilotes et fournissant des interfaces génériques et normalisées aux applications souhaitant l’utiliser. Enfin, la troisième couche, les applications EFI, en majeure partie les _bootloaders_ donc... Alors, si vous trouvez que ça ressemble à BIOS + OS + applications, difficile d’argumenter tellement ça semble exact ! Au passage, _a priori_, une application EFI dépend de l’architecture : elle sera x86, x86-64, ia64. Concrètement, comment identifier un EFI ? ========================================= Hum, c’est une bonne question. Je dispose depuis quelques jours d’un ordinateur portable ASUS utilisant un magnifique UEFI. Mais par défaut, une émulation du BIOS est présente, permettant de lancer un [[GRUB]] sans soucis. Pire encore, par défaut, le _boot_ EFI n’est même pas activé sur les clés USB, par exemple. J’avoue ne pas avoir trouvé de solution depuis GNU/Linux pour le savoir. À vrai dire, c’est le but de l’émulation du BIOS, non ? Et le Windows n’a pas vécu assez longtemps (0 seconde) pour vérifier. Seul un passage par l’interface de configuration du _firmware_ (ce que, par abus de langage, on appelait BIOS) prouve que l’on est face à une machine EFI. Heureusement, ici, pas d’interface graphique qui bouge dans tous les sens. Nous avons une interface sobre, classique, contrôlée au clavier, avec des options comme « UEFI Boot », pour nous mettre sur la voie. Bootons en EFI ============== Dans mon ignorance, j’ai installé ma Debian classiquement, sans réfléchir : 256 Mio pour un `« /boot »` en ext3, le reste en volume physique LVM, un GRUB, et ça roule ! Et je ne peux donc pas profiter d’un _boot_ EFI : le chargeur d’amorçage (_boot loader_) pour EFI doit être stocké sur une partition pour laquelle un pilote est chargé. Ne pouvant ajouter de pilote ext3 dans mon _firmware_, je me vois contraint d’avoir une partition FAT pour le chargeur d’amorçage ! Mon premier objectif n’étant pas la destruction de mon amour propre et de ma distribution, j’opte donc pour une solution plus sage : _booter_ en EFI sur une clé USB. Le _boot_ EFI 100 % natif top moumoute viendra plus tard. Préparons donc une clé USB à _booter_ en EFI. Mais que mettre dessus ? Mettre un GRUB classique pour un BIOS, je sais faire. Mais un EFI ne mange pas de ce pain. Ma clé USB était une clé USB classique, partitionnée avec une table de partitions DOS et une seule partition FAT32. Je décidai, pour l’expérience, de la maltraiter un peu. Mais, normalement, vous n’avez pas à la maltraiter à ce point. Donc maltraitons‐la : passons‐la en [GPT](http://fr.wikipedia.org/wiki/GUID_Partition_Table), nouveau format de table de partitions, permettant de passer outre la limite des 2 Tio (indispensable sur une clé de 8 Gio). Pour ce faire, [[_parted_]] est notre ami, avec la commande `« mklabel gpt »` (ce journal ne visant pas à faire de vous un expert de `parted`, je n’irai pas plus loin). Il suffit donc d’avoir une table des partitions valide, comprise du BIOS, et d’y glisser subtilement une partition FAT. Faisons donc. Mais que mettre sur cette partition FAT, et où ? C’est là où j’ai perdu le plus de temps finalement. J’avais expliqué tantôt que l’EFI charge une application, la plupart du temps un chargeur d’amorçage. Mais je ne suis pas fou, je ne vais pas directement tenter GRUB. Tentons plus simple, plus utile aussi, pour une clé USB : l’_EFI shell_ (explications dans un paragraphe, j’ai pas trouvé mieux comme organisation). Le projet tiano-core, une implémentation libre du cœur d’UEFI, nous fournit ce _shell_ à l’adresse suivante : . Mettons ce _shell_ sur la clé USB. Pour cela, je crée un dossier EFI, et je mets dedans le fichier `« shell.efi »`. Mais ça ne marche pas (n’essayez pas). En effet, il faut mettre un bon nom au fichier. Le fichier d’amorçage, dans le cas d’une clé USB en x86-64, doit être à l’emplacement suivant : `« \EFI\boot\bootx64.efi »`. Notez l’utilisation de la notation x64 pour parler d’x86-64, que l’on nomme amd64, x64 est la notation de Sun et Microsoft. Et la contre‐oblique (anti‐slash) est de mise en EFI. Une fois le fichier mis sur la clé et la machine démarrée, on se retrouve dans le grandiose EFI shell ! Le shell EFI ============ Le premier qui dit que ça ressemble à DOS, gagne un cadeau Bonux. Notons tout d’abord la liste des périphériques bloc détectés, affichée en haut de l’écran au lancement du _shell_. Un conseil : ajoutez immédiatement ce logiciel dans votre trousse à outils pour dépanner des machines. Je ne plaisante pas : il me semble être tout simplement indispensable, pour les futurs EFI bogués, de disposer de cet outil et des quelques utilitaires qu’il propose. Vous voici maintenant devant un _shell_ à l’invite fort engageante, couleur jaune sur un fond noir :> `Shell>` Voici les commandes qui m’ont semblé intéressantes (je ne m’amuserai plus à recopier tout le résultat des commandes) : - `help :` l’indispensable ; - `drivers :` liste l’ensemble des pilotes chargés dans l’UEFI. Comme ça, quand votre clé USB 4 ne fonctionnera pas, vous pourrez charger un pilote USE 4 depuis votre clé USB 3 ; - `devices :` liste les périphériques connus, mais c’est moins joli que _devtree_. Sur mon PC portable, j’ai 8 périphériques :>- fs0 alias hd22b0d0b _(après plusieurs reboots : cet identifiant est dynamique)_ alias blk0 : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)/HD(Part1,Sig64ED66EC-D248-412A-AEEB-B0ECA830E264)>- blk1 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part1,Sig0003AC8C)>- blk2 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part2,Sig0003AC8C)>- blk3 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)>- blk4 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(2,0)>- blk5 : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0) OK, facile de deviner : _fs0_ est la partition 1 de la clé USB. Mais que faire d’autre maintenant ? Mouais... Pas super fun. Au passage, vous verrez des commandes pour le support de DHCP, d’IPv4. Rien pour IPv6 par contre. Ça c’est l’avenir. Explorons donc plutôt le système de fichiers. Vous vous souvenez bien de DOS ? Si oui, c’est facile :> `fs0:` Et voilà, vous êtes dans le disque `fs0`... Puis, vous pouvez utiliser les bonnes vieilles commandes DOS du type `« cd »`, `« dir »` (ou `« ls »`, ouf !), type (et pas `« cat »`)... Mais passons à plus rigolo : _bootons_ un Linux depuis EFI ! efilinux ======== _efilinux_ est une solution très récente et très simple pour amorcer un Linux depuis EFI. C’est le [[LILO]] d’EFI, en quelque sorte. Il est disponible en paquet Debian, et contient principalement le fichier suivant : `« /usr/lib/efilinux/efilinux.efi »`. On va donc mettre `« efilinux.efi »` sur la clé USB et l’accompagner d’un _vmlinuz_ et de l’_initrd_ correspondant. On se retrouve donc avec dans `« fs0:/EFI » les fichiers suivants : - `« boot\bootx64.efi »`, le shell ; - `« vmlinuz-3.1.0-rc7-amd64 »` ; - `« initrd-3.1.0-rc7-amd64 »` ; - `« efilinux.efi »`. La méthode d’amorçage est très très simple : ```text fs0: cd EFI efilinux.efi -f 0:\EFI\vmlinuz-3.1.0-rc7-amd64 root=/dev/mapper/asus--laptop-root ro initrd=0:\EFI\initrd-3.1.0-rc7-amd64 ``` Et voilà ! Vous avez amorcé votre premier noyau avec un système EFI « pur ». Et vous verrez la différence : ```bash $ dmesg | grep -c -i efi 308 ``` Contre 0 ou 1 auparavant... Devant la longueur de ce journal, il est urgent d’attendre avant de continuer. Prochain épisode : je remplace GRUB par un gestionnaire d’amorçage UEFI... Puis, je code une appli UEFI ! Remerciements ============= Merci à ASUS de rembourser Windows, sans me priver de ma machine... Merci à Matthew Garrett pour son magnifique _blog_ et ses grandes explications sur EFI... Et merci à Debian pour exister... P.‐S. : je ne peux garantir que tout ceci fonctionne sur une machine Apple, tout simplement parce qu’elles utilisent une solution bâtarde entre EFI et UEFI, avec un comportement souvent différent de ce que l’on voit sur les machines des autres constructeurs.

AltStyle によって変換されたページ (->オリジナル) /