URL: https://linuxfr.org/users/pied/journaux/uefi-%C3%A0-la-d%C3%A9couverte-du-nouveau-bios%E2%80%A6 Title: UEFI, à la découverte du nouveau BIOS... Authors: Pinaraf Date: 2011年10月25日T00:45:13+02:00 License: CC By-SA Tags: uefi, efi, bios et debian Score: 81 Qu'il semble loin le temps, béni pour certains, maudits pour d'autres, où il était nécessaire de connaître les IRQs et DMAs de sa machine pour l'utiliser, où, loin du Plug'n'Pray, 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. Qui est-il, que fait-il, pourquoi disparaît-il ? 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 reverse engineering, des fabricants ont pu commencer à vendre des clones 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 : scroll, changer le mode, les 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, le boot 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 To... 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 plateforme 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é que 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. 2210 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 booter 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 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 secondes) pour vérifier... Seul un passage par l'interface de configuration du firmware (ce que, par abus de langage, on appellait 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 Mo pour un /boot en ext3, le reste en PV LVM, un grub, et ça roule... Et je ne peux donc pas profiter d'un boot EFI : le bootloader 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 bootloader ! 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écidais, 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, nouveau format de table de partitions, permettant de passer outre la limite des 2To (indispensable sur une clé de 8Go). 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 bootloader. Mais je ne suis pas fou, je 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 : http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UEFI_Shell 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 de boot, 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 l'anti-slash est de mise en EFI) Une fois le fichier mis sur la clé, et la machine bootée, on se retrouve dans le grandiose EFI shell ! Le shell EFI ============ 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 buggé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> Le premier qui dit que ça ressemble à DOS gagne un cadeau bonux... Notons tout d'abord la liste des périphériques blocs détectés, affichée en haut de l'écran au lancement du shell. Sur mon PC portable, j'en ai 8 : - fs0 alias hd22b0d0b (après plusieurs reboot : cet identifiant est dynamique) alias blk0 Chemin complet : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)/HD(Part1,Sig64ED66EC-D248-412A-AEEB-B0ECA830E264) - blk1 Chemin complet : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part1,Sig0003AC8C) - blk2 Chemin complet : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part2,Sig0003AC8C) - blk3 Chemin complet : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0) - blk4 Chemin complet : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(2,0) - blk5 Chemin complet : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0) Ok, facile de deviner : fs0 est la partition 1 de clé USB. Mais que faire d'autre maintenant... Je ne m'amuserai plus à recopier tout le résultat des commandes, voici les commandes qui m'ont semblé intéressantes : - 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 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 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 booter 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 de boot est très très simple : 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 booté votre premier noyau avec un système EFI «pur». Et vous verrez la différence : 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 bootloader 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 によって変換されたページ (->オリジナル) /