Démarrage UEFI : comment cela fonctionne-t-il alors ?

C'est à nouveau l'heure de la rédaction d'AdamW ! Si vous cherchez quelque chose de court et vif, cherchez ailleurs.

Kamil Paral m'informe gentiment que je souffre de graphomanie chronique. Toujours agréable de savoir ce qui ne va pas chez toi.

REMARQUE IMPORTANTE POUR LES GENS DE L'INDUSTRIE : Cet article de blog s'adresse aux gens ordinaires; il est destiné à dissiper quelques mythes courants et à aider les gens ordinaires à mieux comprendre l'UEFI. Ce n'est pas une explication de bas niveau entièrement détaillée et techniquement précise à 100%, et je ne suis pas un ingénieur de firmware professionnel ou quelque chose comme ça. Si vous construisez réellement un système d'exploitation ou du matériel ou quelque chose du genre, veuillez ne pas vous fier à mes explications simplifiées ou me demander de l'aide ; Je ne suis qu'un idiot sur Internet. Si vous faites ce genre de chose et que vous avez de l'argent, rejoignez le Forum UEFI ou demandez à vos fournisseurs ou vérifiez votre implémentation de référence ou autre. Si vous n'avez pas d'argent, essayez gentiment de demander à vos pairs plus expérimentés. FIN REMARQUE IMPORTANTE

Vous avez probablement lu beaucoup de choses sur Internet à propos de l'UEFI. Voici quelque chose d'important que vous devez comprendre : 95 % d'entre eux étaient probablement des ordures. Si vous pensez connaître l'UEFI et que vous avez obtenu vos connaissances ailleurs que dans les spécifications UEFI, le blog de mjg59 ou l'un des quelques autres lieux/personnes vaguement fiables – Rod Smith, ou Peter Jones, ou Chris Murphy, ou la documentation de l'UEFI relativement peu de systèmes d'exploitation dont les développeurs savent réellement ce qu'ils font avec UEFI – ce que vous pensez savoir est probablement un mélange toxique de malentendus, d'idées fausses, de demi-vérités, de propagande et de mensonges purs et simples. Donc, vous devriez probablement tout oublier.

Bien, maintenant nous avons réglé ça. Ce dont je veux surtout parler, c'est du bootloading, parce que c'est le micrologiciel qui compte le plus pour la plupart des gens, et les sites d'actualités parlent toujours de malentendus et de malentendus.

Terminologie

Tout d'abord, débarrassons-nous d'un peu de terminologie. Le BIOS et l'UEFI sont tous deux des types de micrologiciels pour ordinateurs. Le micrologiciel de style BIOS ne se trouve (la plupart du temps) que sur les ordinateurs compatibles IBM PC. UEFI est censé être plus générique et peut être trouvé sur des systèmes qui ne sont pas dans la classe « IBM PC compatible ».

Vous n'avez pas de 'UEFI BIOS'. Personne n'a de 'UEFI BIOS'. Veuillez ne jamais dire « UEFI BIOS ». Le BIOS n'est pas un terme générique pour tous les microprogrammes de PC, c'est un type particulier de microprogramme de PC. Votre ordinateur a un firmware. S'il s'agit d'un ordinateur compatible IBM PC, il s'agit presque certainement d'un BIOS ou d'un micrologiciel UEFI. Si vous utilisez Coreboot, félicitations, M./Mme. Exception. Vous pouvez être fier de vous.

Secure Boot n'est pas la même chose que UEFI. N'utilisez jamais ces termes de manière interchangeable. Le démarrage sécurisé est un élément unique et effectivement facultatif de la spécification UEFI, qui a été ajouté dans la version 2.2 de la spécification UEFI. Nous parlerons précisément de ce que c'est plus tard, mais pour l'instant, n'oubliez pas que ce n'est pas la même chose à propos de l'UEFI. Vous devez comprendre ce qu'est Secure Boot, ce qu'est l'UEFI et lequel des deux vous parlez réellement à un moment donné. Nous parlerons d'abord de UEFI, puis de Secure Boot en tant qu'« extension » de UEFI, car c'est essentiellement ce dont il s'agit.

Bonus Note Historique: UEFI n'a pas été inventé par, n'est pas contrôlé par et n'a jamais été contrôlé par Microsoft. Son prédécesseur et sa base, EFI, a été développé et publié par Intel. L'UEFI est géré par le Forum UEFI. Microsoft est membre du forum UEFI. Il en va de même pour Red Hat, tout comme Apple, ainsi que pour à peu près tous les principaux fabricants de PC, Intel (évidemment), AMD et une liste exhaustive d'autres sociétés et organisations majeures et mineures de matériel, de logiciels et de micrologiciels. C'est une spécification largement consensuelle, avec tout le désordre que cela implique, dont nous parlerons spécifiquement plus tard. Ce n'est le véhicule maléfique du mal d'aucune entreprise.

Les références

Si vous voulez vraiment comprendre UEFI, c'est une très bonne idée d'aller lire la spécification UEFI. Tu peux le faire. C'est très facile. Vous n'avez à payer d'argent à personne. Je ne vais pas vous dire que le lire sera le plus amusant que vous ayez jamais eu, car ce ne sera pas le cas. Mais ce ne sera pas une perte de temps. Vous pouvez le trouver ici sur le site officiel de l'UEFI. Vous devez cocher quelques cases, mais vous ne signez pas votre âme à Satan, ou quoi que ce soit. C'est bon. Au moment où j'écris ceci, la version actuelle de la spécification est 2.4 Errata A, et c'est la version pour laquelle cet article est écrit.

Il n'y a pas de spécification BIOS. Le BIOS est un de facto standard – cela fonctionne de la même manière que sur les vrais PC IBM, dans les années 1980. C'est en quelque sorte l'une des raisons pour lesquelles l'UEFI existe.

Maintenant, pour garder les choses simples, considérons deux mondes. L'un est le monde des ordinateurs compatibles IBM PC – ci-après appelés simplement PC – avant l'existence de l'UEFI et du GPT (nous viendrons à GPT). C'est le monde que beaucoup d'entre vous connaissent probablement et peuvent très bien comprendre. Parlons du fonctionnement du démarrage sur les PC dotés du micrologiciel BIOS.

démarrage du BIOS

Cela fonctionne, en fait, d'une manière très, très simple. Sur votre PC BIOS old-skool standard, vous avez un ou plusieurs disques qui ont un MBR. Le MBR est une autre norme de facto ; fondamentalement, le tout début du disque décrit les partitions sur le disque dans un format particulier et contient un « chargeur de démarrage », un très petit morceau de code qu'un micrologiciel du BIOS sait exécuter, dont le travail consiste à démarrer le système d'exploitation système(s). (Les chargeurs de démarrage modernes sont souvent beaucoup plus gros que ce qui peut être contenu dans l'espace MBR et doivent utiliser une conception à plusieurs étages où le bit dans le MBR sait juste comment charger la prochaine étape depuis un autre endroit, mais ce n'est pas important pour nous en ce moment ).

Tout ce qu'un microprogramme BIOS sait, dans le contexte du démarrage du système, ce sont les disques que le système contient. Vous, le propriétaire de cet ordinateur basé sur le BIOS, pouvez indiquer au micrologiciel du BIOS à partir de quel disque vous voulez qu'il démarre le système. Le firmware n'a aucune connaissance de quoi que ce soit au-delà de cela. Il exécute le chargeur de démarrage qu'il trouve dans le MBR du disque spécifié, et c'est tout. Le firmware n'est plus impliqué dans le démarrage.

Dans le monde du BIOS, absolument toutes les formes de multi-démarrage sont gérées au-dessus de la couche du micrologiciel. La couche du micrologiciel ne sait pas vraiment ce qu'est un chargeur de démarrage ou ce qu'est un système d'exploitation. Bon sang, il ne sait pas ce qu'est une partition. Tout ce qu'il peut faire est d'exécuter le chargeur de démarrage à partir du MBR d'un disque. Vous ne pouvez pas non plus configurer le processus de démarrage depuis l'extérieur du micrologiciel.

Démarrage UEFI : arrière-plan

OK, nous avons donc notre expérience, le monde du BIOS. Voyons maintenant comment le démarrage fonctionne sur un système UEFI. Même si vous ne saisissez pas les détails de cet article, saisissez ceci : c'est complètement différent. Complètement et totalement différent du fonctionnement du démarrage du BIOS. Vous ne pouvez pas appliquer votre compréhension du démarrage du BIOS au démarrage UEFI natif. Vous ne pouvez pas modifier un peu un système conçu pour le monde du démarrage du BIOS et l'appliquer à originaire de Démarrage UEFI. Vous devez comprendre que c'est un monde complètement différent.

Voici une autre chose importante à comprendre : de nombreux firmwares UEFI implémentent une sorte de Mode de compatibilité BIOS, parfois appelé CSM. De nombreux micrologiciels UEFI peuvent démarrer un système comme le ferait un micrologiciel BIOS – ils peuvent rechercher un MBR sur un disque et exécuter le chargeur de démarrage à partir de ce MBR, puis tout laisser à ce chargeur de démarrage. Les gens parfois incorrectement faire référence à l'utilisation de cette fonctionnalité en tant que « désactivation de l'UEFI », qui est linguistiquement absurde. Vous ne pouvez pas « désactiver » le micrologiciel de votre système. C'est juste un terme stupide. Ne l'utilisez pas, mais comprenez ce que les gens veulent vraiment dire quand ils le disent. Ils parlent d'utiliser la capacité d'un micrologiciel UEFI pour démarrer le système « style BIOS » plutôt que le style UEFI natif.

Ce que je vais décrire est originaire de Démarrage UEFI. Si vous avez un système basé sur UEFI dont le micrologiciel dispose de la fonction de compatibilité BIOS, et que vous décidez de l'utiliser, et que vous appliquez cette décision de manière cohérente, alors en ce qui concerne le démarrage, vous pouvez prétendre que votre système est basé sur le BIOS, et simplement faites tout comme vous l'avez fait avec un démarrage de style BIOS. Si vous comptez le faire, assurez-vous simplement que vous faire l'appliquer systématiquement. Je ne peux vraiment pas recommander assez fortement que vous fassiez ne pas tenter de mélanger le démarrage natif UEFI et compatible BIOS de systèmes d'exploitation installés de façon permanente sur le même ordinateur, et surtout pas sur le même disque. C'est une idée terrible et terrible et vous causera du chagrin et de la douleur. Si vous décidez de le faire, ne venez pas pleurer vers moi.

Pour des raisons de santé mentale, je vais supposer l'utilisation de disques avec une table de partition GPT et des partitions système EFI FAT32 EFI. Selon la profondeur à laquelle vous allez plonger dans ce genre de choses, vous peut découvrir que ce n'est pas à proprement parler le cas que vous pouvez toujours supposez que vous aurez affaire à des disques GPT et à des ESP EFI FAT32 lors du démarrage natif UEFI, mais la spécification UEFI est assez fortement liée aux disques GPT et aux ESP EFI FAT32, et c'est ce à quoi vous aurez affaire dans 99% des cas cas. À moins que vous n'ayez affaire à des Mac, et franchement, vis Mac.

Note éditée: les sections suivantes (jusqu'à Implications et complications) ont été fortement révisés le 2014-01-26, quelques heures après la publication de la version initiale de ce message, sur la base des commentaires de Peter Jones. Considérez qu'il s'agit de la v2.0 du message. Une version antérieure a été écrite d'une manière un peu moins précise et plus confuse.

Démarrage natif UEFI : comment cela fonctionne-t-il réellement ?

OK, avec ça à l'écart, passons à la viande. C'est ainsi que fonctionne le démarrage UEFI natif. Il est probablement utile d'aborder cela avec un peu d'arrière-plan de haut niveau.

UEFI fournit beaucoup plus d'infrastructure au niveau du micrologiciel pour gérer le démarrage du système. C'est loin d'être aussi simple que le BIOS. Contrairement au BIOS, l'UEFI comprend certainement, à des degrés divers, les concepts de « partitions de disque », de « chargeurs de démarrage » et de « systèmes d'exploitation ».

Vous pouvez en quelque sorte examiner le processus de démarrage du BIOS et le processus UEFI et voir comment le processus UEFI étend divers bits pour résoudre des problèmes spécifiques.

L'approche BIOS/MBR pour trouver le chargeur de démarrage est assez bizarre, quand on y pense. C'est une "sauce spéciale" : ce petit espace particulier à l'avant du disque contient du code magique qui n'a vraiment de sens que pour le micrologiciel du système et des utilitaires spéciaux pour l'écrire. Il y a plusieurs problèmes avec cette approche.

• C'est peu pratique à gérer – vous avez besoin d'utilitaires spéciaux pour écrire le MBR, et à peu près le seul moyen de découvrir ce qu'il contient est d'en extraire le contenu et de l'examiner.
• Comme indiqué ci-dessus, le MBR lui-même n'est pas assez grand pour de nombreux chargeurs de démarrage modernes. Ce qu'ils font, c'est installer une petite partie d'eux-mêmes sur le MBR proprement dit, et le reste dans l'espace vide du disque entre la fin du MBR conventionnel et le début de la première partition. Il y a un gros problème avec ça (enfin, toute la conception est un gros problème, mais peu importe), c'est qu'il n'y a pas de convention fiable pour savoir où la première partition doit commencer, il est donc difficile d'être sûr qu'il y aura assez d'espace . Une chose sur laquelle vous pouvez généralement compter est qu'il n'y aura pas assez de l'espace pour certaines configurations de bootloader.
• La conception ne fournit aucune couche ou mécanisme standardisé pour sélectionner des cibles de démarrage autres que les disques… mais les gens vouloir pour sélectionner des cibles de démarrage autres que des disques. c'est-à-dire qu'ils veulent avoir plusieurs « choses » amorçables – généralement des systèmes d'exploitation – par disque. La seule façon de le faire, dans le monde BIOS/MBR, est que les chargeurs de démarrage le gèrent ; mais il n'y a pas de convention largement acceptée pour la bonne façon de le faire. Il existe de nombreuses approches différentes, dont aucune n'est particulièrement interopérable avec les autres, aucune n'est une norme ou une convention largement acceptée, et il est très difficile d'écrire des outils au niveau de la couche d'installation du système d'exploitation / système d'exploitation qui gère correctement le multiboot. C'est juste une conception très désordonnée.
• La conception ne fournit pas de moyen standard de démarrer à partir de quoi que ce soit sauf disques. Nous n'allons pas vraiment en parler dans cet article, mais sachez simplement que c'est un autre avantage du démarrage UEFI : il fournit un moyen standard de démarrer à partir, par exemple, d'un serveur distant.
• Il n'y a pas de mécanisme pour les niveaux supérieurs au firmware pour configurer le comportement de démarrage du firmware.

Vous pouvez donc imaginer les elfes UEFI assis et considérant ce problème et proposant une solution. Au lieu que le micrologiciel ne connaisse que les disques et un emplacement « magique » par disque où le code du chargeur de démarrage pourrait résider, l'UEFI dispose de beaucoup plus d'infrastructure au niveau de la couche du micrologiciel pour gérer le chargement du démarrage. Regardons toutes les choses qu'il définit qui sont pertinentes ici.

exécutables EFI

La spécification UEFI définit un format exécutable et exige que tous les firmwares UEFI soient capables d'exécuter du code dans ce format. Lorsque vous écrivez un chargeur de démarrage pour l'UEFI natif, vous écrivez dans ce format. C'est assez simple et direct, et n'a pas besoin d'explications supplémentaires : c'est juste une bonne chose que nous ayons maintenant une spécification de firmware qui définit en fait un format commun pour le code que le firmware peut exécuter.

Le format GPT (GUID partition table)

Le format de la table de partition GUID est très lié à la spécification UEFI, et encore une fois, ce n'est pas quelque chose de particulièrement complexe ou nécessitant beaucoup d'explications, c'est juste un bon travail de base fourni par la spécification. GPT est juste une norme pour créer des tables de partition – les informations au début d'un disque qui définissent les partitions que contient ce disque. C'est une meilleure norme pour ce faire que les tables de partition MBR/'MS-DOS' étaient à bien des égards, et la spécification UEFI exige que les firmwares compatibles UEFI soient capables d'interpréter GPT (elle exige également qu'ils soient capables d'interpréter MBR, par exemple rétrocompatibilité). Tout cela est un travail de base utile : ce qui se passe ici, c'est que la spécification établit certaines capacités que tout ce qui se trouve au-dessus de la couche du micrologiciel peut s'appuyer sur le micrologiciel.

Partitions système EFI

En fait, je me suis vraiment penché sur le concept de partition système EFI lors de la révision de cet article, et c'était un super "aha!" moment. Vraiment, le concept de « partitions système EFI » n'est qu'une réponse au problème de l'espace MBR « sauce spéciale ». Le concept d'une quantité indéfinie d'espace vide au début d'un disque étant « où réside le code du chargeur de démarrage » est une conception assez merdique, comme nous l'avons vu ci-dessus. Les partitions système EFI ne sont que la solution d'UEFI à cela.¹

La solution est la suivante : nous exigeons que la couche du firmware soit capable de lire certains types spécifiques de système de fichiers. La spécification UEFI exige que les firmwares conformes soient capables de lire les variantes FAT12, FAT16 et FAT32 du format FAT, essentiellement. En fait, ce qu'il fait, c'est codifier une interprétation particulière de ces formats tels qu'ils existaient au moment où l'UEFI a été accepté, et dire que les firmwares compatibles UEFI doivent être capables de lire ces formats. Comme le dit la spécification :

« Le système de fichiers pris en charge par l'interface de micrologiciel extensible est basé sur le système de fichiers FAT. EFI définit une version spécifique de FAT qui est explicitement documentée et testable. La conformité à la spécification EFI et à ses documents de référence associés est la seule définition de FAT qui a besoin à implémenter pour prendre en charge EFI. Pour différencier le système de fichiers EFI du FAT pur, un nouveau type de système de fichiers de partition a été défini.

Une "partition système EFI" est en fait n'importe quelle partition formatée avec l'une des variantes de FAT définies par les spécifications UEFI et dotée d'un type de partition GPT spécifique pour aider le micrologiciel à la trouver. Et le but de ceci est exactement comme décrit ci-dessus : permettre à chacun de s'appuyer sur le fait que la couche du firmware sera certainement capable de lire les données d'une partition de disque assez «normale». Espérons qu'il soit clair pourquoi il s'agit d'une meilleure conception : au lieu d'avoir à écrire le code du chargeur de démarrage dans l'espace « magique » au début d'un disque MBR, les systèmes d'exploitation et ainsi de suite peuvent simplement créer, formater et monter des partitions dans un format largement compris et mettre le code du chargeur de démarrage et tout ce qu'ils pourraient vouloir que le micrologiciel lise là-bas.

L'ensemble de l'ESP m'a semblé un peu bizarre et déroutant au début, alors j'espère que cette section explique pourquoi c'est en fait une idée très sensée et une bonne conception – la chose bizarre et déroutante est vraiment la conception du BIOS/MBR, où le seul moyen pour que vous écriviez quelque chose à partir de la couche du système d'exploitation que vous saviez que la couche du micrologiciel pouvait consommer, c'était de l'écrire dans certains (mais vous ne saviez pas combien) Magic Space au début d'un disque, une convention qui n'est pas réellement codifiée partout. C'est vraiment n'est pas une conception très sensée ou compréhensible, si vous prenez du recul et l'examinez.

Comme nous le noterons plus tard, la spécification UEFI a tendance à adopter une approche « vous devez au moins faire ces choses » – elle interdit rarement aux firmwares de faire autre chose. Il n'est pas contraire aux spécifications d'écrire un micrologiciel capable d'exécuter du code dans d'autres formats, de lire d'autres types de table de partition et de lire des partitions formatées avec des systèmes de fichiers autres que les variantes UEFI de FAT. Mais un firmware compatible UEFI doit au moins faites toutes ces choses, donc si vous écrivez un système d'exploitation ou quelque chose d'autre sur lequel vous voulez exécuter tout Micrologiciel compatible UEFI, c'est pourquoi le concept de partition système EFI est si important : il vous donne (au moins en théorie) 100% de confiance que vous pouvez mettre un exécutable EFI sur une partition formatée avec l'implémentation UEFI FAT et le bon type de partition GPT , et le micrologiciel du système pourra le lire. C'est la chose que vous pouvez apporter à la banque, comme "le firmware sera capable d'exécuter le code du chargeur de démarrage que j'ai mis dans l'espace MBR" était dans le monde du BIOS.

Nous avons donc maintenant trois éléments de base importants fournis par la spécification UEFI : grâce à ces exigences, toute autre couche peut s'appuyer en toute confiance sur le fait que le micrologiciel :

• Peut lire une table de partition
• Peut accéder aux fichiers dans certains systèmes de fichiers spécifiques
• Peut exécuter du code dans un format particulier

C'est bien plus que ce dont vous pouvez compter sur un micrologiciel BIOS. Cependant, afin de compléter la vision d'une couche de micrologiciel capable de gérer le démarrage de plusieurs cibles – pas seulement des disques – nous avons besoin d'un autre travail de base : il doit y avoir un mécanisme par lequel le micrologiciel trouve les différentes cibles de démarrage possibles et un moyen de le configurer.

Le gestionnaire de démarrage UEFI

La spécification UEFI définit quelque chose appelé le gestionnaire de démarrage UEFI. (Les distributions Linux contiennent un outil appelé efibootmgr qui est utilisé pour manipuler la configuration du gestionnaire de démarrage UEFI). À titre d'exemple de ce que vous pouvez vous attendre à trouver si vous lisez la spécification UEFI, elle définit ainsi le gestionnaire de démarrage UEFI :

"Le gestionnaire de démarrage UEFI est un moteur de politique de micrologiciel qui peut être configuré en modifiant les variables NVRAM globales définies architecturalement. Le gestionnaire de démarrage tentera de charger les pilotes UEFI et les applications UEFI (y compris les chargeurs de démarrage UEFI OS) dans un ordre défini par les variables NVRAM globales ."

Eh bien, c'est réglé, passons à autre chose. 😉 Non, pas vraiment. Traduisons cela en humain. Avec seulement un degré raisonnable de simplification, vous pouvez considérer le gestionnaire de démarrage UEFI comme un menu de démarrage. Avec un micrologiciel BIOS, votre "menu de démarrage" de niveau de micrologiciel correspond, nécessairement, aux disques connectés au système au moment du démarrage – ni plus, ni moins. Ce n'est pas vrai avec un firmware UEFI.

Le gestionnaire de démarrage UEFI peut être configuré – en termes simples, vous pouvez ajouter et supprimer des entrées du "menu de démarrage". Le micrologiciel peut également (en fait, la spécification l'exige, dans divers cas) efficacement « générer » des entrées dans ce menu de démarrage, en fonction des disques connectés au système et éventuellement de certains paramètres de configuration du micrologiciel. Il peut également être examiné – vous pouvez regarder ce qu'il contient.

L'UEFI propose un mécanisme pour le faire. d'autres couches: vous pouvez configurer le comportement de démarrage du système à partir d'un système d'exploitation démarré. Vous pouvez faire tout cela en utilisant le efibootmgr outil, une fois que Linux a démarré via UEFI d'une manière ou d'une autre. Il existe également des outils Windows pour cela, mais je ne les connais pas très bien. Regardons quelques exemples typiques efibootmgr sortie, que j'ai volée et légèrement modifiée sur les forums Fedora :

[root@system directory]# efibootmgr -v
Courant de démarrage : 0002
Délai d'attente : 3 secondes
Ordre de démarrage : 0003 000 000 000 000 0004
Boot0000* BIOS du lecteur de CD/DVD (3,00)
Boot0001* Disque dur HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)Fichier(EFIfedoragrubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)Fichier(EFIopensusegrubx64.efi)
Boot0004* BIOS du disque dur(2,0,00)P0 : ST1500DM003-9YN16G .
[root@system directory]#

C'est un bel exemple propre que j'ai volé et légèrement modifié sur les forums Fedora. Nous pouvons voir quelques choses se passer ici.

La première ligne vous indique à quelle entrée du « menu de démarrage » vous vous trouvez actuellement démarré à partir de. La seconde est assez évidente (si le micrologiciel présente une interface de type menu de démarrage au gestionnaire de démarrage UEFI, c'est le délai avant qu'il ne démarre et démarre l'entrée par défaut). Le BootOrder est l'ordre dans lequel les entrées de la liste seront essayées. Le reste de la sortie montre les entrées de démarrage réelles. Nous décrirons ce qu'ils font réellement plus tard.

Si vous démarrez un firmware UEFI tout à fait normalement, sans faire aucun des réglages dont nous parlerons plus tard, ce qu'il devrait faire est d'essayer de démarrer à partir de chacune des "entrées" dans le "menu de démarrage", dans l'ordre indiqué dans Ordre de démarrage. Ainsi, sur ce système, il essaierait de démarrer l'entrée appelée « opensuse », puis si cela échouait, celle appelée « Fedora », puis « lecteur CD/DVD », puis le second « Disque dur ».

Démarrage natif UEFI : comment cela fonctionne réellement – entrées du gestionnaire de démarrage

Qu'est-ce que ces entrées en fait moyenne, bien que? Il y a en fait un énorme gamme de possibilités qui constitue à elle seule une grande partie de la complexité de la spécification UEFI. Si vous lisez les spécifications, versez-vous une très grande dose de gin et passez à la section EFI_DEVICE_PATH_PROTOCOL, mais notez qu'il s'agit d'un protocole générique qui est utilisé pour d'autres choses que le démarrage – c'est la manière officielle d'identifier les périphériques à toutes fins de l'UEFI, utilisé pour les entrées du gestionnaire de démarrage mais aussi pour toutes sortes d'autres fins. Tous les chemins de périphérique EFI possibles n'ont pas de sens en tant qu'entrée du gestionnaire de démarrage UEFI, pour des raisons évidentes (vous n'irez probablement pas trop loin en essayant de démarrer à partir de votre carte vidéo). Mais vous pouvez certainement avoir une entrée qui pointe vers, disons, un serveur PXE, pas une partition de disque. La spécification contient de nombreux bits définissant des cibles de démarrage non disque valides qui peuvent être ajoutées à la configuration du gestionnaire de démarrage UEFI.

Pour nos besoins, cependant, considérons simplement les disques assez normaux connectés au système. Dans ce cas, nous pouvons considérer trois types d'entrées que vous êtes susceptible de rencontrer.

Entrées de démarrage de compatibilité BIOS

Boot0000 et Boot0004 dans cet exemple sont en fait des entrées de mode de compatibilité BIOS, et non des entrées natives UEFI. Ils n'ont été ajoutés à la configuration du gestionnaire de démarrage UEFI par aucune agence externe, mais générés par le micrologiciel lui-même. démarrage d'un appareil donné. Comment ils présentez-le à l'utilisateur est une autre question, comme nous le verrons plus tard. Que vous voyiez ou non l'une de ces entrées dépendra de votre micrologiciel particulier et de sa configuration. Chacune de ces entrées donne juste un nom – 'CD/DVD Drive', 'Hard Drive' – et dit "si cette entrée est sélectionnée, démarrez ce disque (où 'ce disque' est 3,0,00 pour Boot0000 et 2,00 pour Boot0004) en mode de compatibilité BIOS".

Entrées de démarrage natives UEFI « chemin de secours »

Boot0001 est une entrée (fictive et quelque peu improbable, mais c'est à des fins d'illustration) qui indique au micrologiciel d'essayer de démarrer à partir d'un disque particulier, et en mode UEFI pas en mode de compatibilité BIOS, mais ne lui dit rien de plus. Il ne spécifie pas de cible de démarrage particulière sur le disque – il dit simplement de démarrer le disque.

La spécification UEFI définit une sorte de chemin de « secours » pour démarrer ce type d'entrée du gestionnaire de démarrage, qui fonctionne en principe un peu comme le démarrage du lecteur BIOS : il recherche dans un emplacement standard un code de chargeur de démarrage. Les détails sont cependant différents.

Ce que le firmware fera réellement en essayant de démarrer de cette manière est assez simple. Le micrologiciel examinera chaque partition système EFI sur le disque dans l'ordre dans lequel elles existent sur le disque. Dans l'ESP, il recherchera un fichier avec un nom et un emplacement spécifiques. Sur un PC x86-64, il cherchera le fichier EFIBOOTBOOTx64.EFI. Ce qu'il recherche en fait, c'est EFIBOOTBOOT{nom abrégé du type de machine}.EFI – 'x64' est le "nom abrégé du type de machine" pour les PC x86-64. Les autres possibilités sont BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Italie), BOOTARM.EFI (AArch32 – c'est-à-dire ARM 32 bits) et BOOTAA64.EFI (AArch64 – c'est-à-dire ARM 64 bits). Il exécutera ensuite le premier fichier qualifié qu'il trouvera (évidemment, le fichier doit être au format exécutable défini dans la spécification UEFI).

Ce mécanisme n'est pas conçu pour démarrer des systèmes d'exploitation installés de façon permanente. Il est plus conçu pour démarrer des supports enfichables à chaud et indépendants des périphériques, comme les images en direct et les supports d'installation du système d'exploitation. Et c'est bien à cela qu'il sert habituellement. Si vous regardez un support en direct ou d'installation compatible UEFI pour une distribution Linux ou un autre système d'exploitation, vous constaterez qu'il possède une table de partition GPT et contient une partition au format FAT au démarrage ou à proximité du périphérique, avec la partition GPT type qui l'identifie comme une partition système EFI. Dans cette partition, il y aura un répertoire EFIBOOT avec au moins un des fichiers spécialement nommés ci-dessus. Lorsque vous démarrez un Fedora live ou installez un support en mode natif UEFI, c'est le mécanisme qui est utilisé. Le fichier BOOTx64.EFI (ou autre) gère le reste du processus de démarrage à partir de là, en démarrant le système d'exploitation réel contenu sur le support.

Entrées de démarrage natives UEFI complètes

Boot0002 et Boot0003 sont des entrées « typiques » pour les systèmes d'exploitation installés en permanence sur des périphériques de stockage permanents. Ces entrées nous montrent toute la puissance du mécanisme de démarrage UEFI, en ne disant pas seulement "démarrer à partir de ce disque", mais "démarrer ce chargeur de démarrage spécifique à cet emplacement spécifique sur ce disque spécifique", en utilisant toutes les "bases" dont nous avons parlé ci-dessus .

Boot0002 est une entrée de démarrage produite par une installation Fedora native UEFI. Boot0003 est une entrée de démarrage produite par une installation OpenSUSE native UEFI. Comme vous pouvez le constater, tout ce qu'ils disent, c'est "charger ce fichier à partir de cette partition". La partition est la HD (1 800 61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) bit : cela fait référence à une partition spécifique (en utilisant le EFI_DEVICE_PATH_PROTOCOL, que je ne vais vraiment pas tenter d'expliquer en détail – vous n'avez pas nécessairement besoin de le savoir, si vous interagissez avec le gestionnaire de démarrage via l'interface du firmware et efibootmgr). Le fichier est le Fichier(EFIopensusegrubx64.efi) bit : cela signifie simplement "charger le fichier à cet emplacement sur la partition que nous venons de décrire". La partition en question sera presque toujours une partition qualifiée de partition système EFI, en raison des considérations ci-dessus : c'est le type de partition auquel nous pouvons faire confiance pour que le micrologiciel puisse accéder.

C'est le mécanisme que la spécification UEFI fournit aux systèmes d'exploitation pour se rendre disponibles pour le démarrage : le système d'exploitation est destiné à installer un chargeur de démarrage qui charge le noyau du système d'exploitation et ainsi de suite sur une partition système EFI, et ajoute une entrée au gestionnaire de démarrage UEFI configuration avec un nom – bien entendu, celui-ci sera généralement dérivé du nom du système d'exploitation – et de l'emplacement du chargeur de démarrage (au format exécutable EFI) destiné à charger ce système d'exploitation.

Les distributions Linux utilisent le efibootmgr outil pour gérer le gestionnaire de démarrage UEFI. Ce que fait réellement une distribution Linux, en ce qui concerne le démarrage, lorsque vous effectuez une installation native UEFI est vraiment assez simple : elle crée une partition système EFI si elle n'existe pas déjà, installe un chargeur de démarrage EFI avec une configuration appropriée – souvent grub2-efi, mais il y en a d'autres – dans un chemin correct dans la partition système EFI, et appelle efibootmgr pour ajouter une entrée de gestionnaire de démarrage UEFI nommée de manière appropriée pointant vers son chargeur de démarrage. La plupart des distributions utiliseront une partition système EFI existante s'il y en a une, bien qu'il soit parfaitement valable d'en créer une nouvelle et de l'utiliser à la place : comme nous l'avons noté, UEFI est une spécification permissive, et si vous suivez la conception logiquement, il y a vraiment aucun problème avec autant de partitions système EFI que vous le souhaitez.

Configuration du processus de démarrage (l'interface utilisateur du firmware)

Ce qui précède décrit le mécanisme de base défini par la spécification UEFI qui gère le processus de démarrage UEFI. Il est important de réaliser que l'interface utilisateur de votre firmware peut ne pas représenter très clairement ce mécanisme. Malheureusement, la spécification s'abstient intentionnellement de définir comment le processus de démarrage doit être représenté pour l'utilisateur ou comment l'utilisateur doit être autorisé à le configurer, et ce que cela signifie – puisque nous avons affaire à des ingénieurs de firmware – c'est que chaque firmware le fait différemment , et certains le font follement.

De nombreux les firmwares ont des interfaces assez raisonnables pour la configuration de démarrage. Une bonne conception de firmware vous montrera au moins l'ordre de démarrage, avec une représentation raisonnable des entrées dessus, et vous permettra d'ajouter ou de supprimer des entrées, de modifier l'ordre ou de remplacer l'ordre d'un démarrage spécifique (en le modifiant juste pour cela boot, ou demander directement au micrologiciel de démarrer une entrée de menu particulière, ou même vous donner la possibilité de simplement dire « démarrer ce disque », soit en mode de compatibilité BIOS ou en mode « de secours » UEFI – mon micrologiciel le fait). Une telle interface affichera souvent les entrées de démarrage natives UEFI « complètes » (comme les exemples Fedora et openSUSE que nous avons vus précédemment) uniquement par leur nom ; vous devez examiner le efibootmgr -v sortie pour savoir précisément ce que ces entrées vont réellement essayer et faire lorsqu'il est invoqué.

Certains firmwares essaient d'abstraire et de simplifier la configuration, et peuvent faire du bon ou du mauvais travail. Par exemple, si vous avez une option pour « activer ou désactiver » le mode de compatibilité du BIOS, ce que cela va vraiment faire est de configurer si le micrologiciel ajoute ou non des entrées de compatibilité BIOS pour les lecteurs connectés à la configuration du gestionnaire de démarrage UEFI. Si vous disposez d'une option pour « activer ou désactiver » le démarrage natif UEFI, ce qui se passe réellement lorsque vous « désactivez » c'est que le micrologiciel modifie la configuration du gestionnaire de démarrage UEFI pour laisser toutes les entrées natives UEFI en dehors du BootOrder.

Le point clé à retenir est que toute option de configuration à l'intérieur de votre interface de micrologiciel qui concerne le démarrage est vraiment, en coulisses, la configuration du comportement du gestionnaire de démarrage UEFI. Si vous comprenez tout ce dont nous avons discuté ci-dessus, vous trouverez peut-être plus facile de comprendre ce qui est vraiment se passe lorsque vous tournez les boutons que votre interface de firmware expose.

Dans le monde du BIOS, vous vous en souviendrez, vous ne trouvez pas toujours que les systèmes sont configurés pour essayer de démarrer à partir de lecteurs amovibles – CD, USB – avant de démarrer à partir de lecteurs permanents. Certains le sont, d'autres non. Certains essaieront le CD avant les disques durs, mais pas l'USB. Les gens se sont assez habitués à devoir vérifier la configuration du BIOS pour s'assurer que l'ordre de démarrage est « correct » lorsqu'ils essaient d'installer un nouveau système d'exploitation.

This applies to the UEFI world too, but because of the added flexibility/complexity of the UEFI boot manager mechanism, it can look unfamiliar and scary.

If you want to ensure that your system tries to boot from removable devices using the 'fallback' mechanism before it tries to boot 'permanent' boot entries – as you will want to do if you want to, say, install Fedora – you need this to be the default for your firmware, or you need to be able to tell the firmware this. Depending on your firmware's interface, you may find there is a 'menu entry' for each attached removable device and you just have to adjust the boot order to put it at the top of the list, or you may find that there is the mechanism to directly request 'UEFI fallback boot of this particular disk', or you may find that the firmware tries to abstract the configuration somehow. We just don't know, and that makes writing instructions for this quite hard. But now you broadly understand how things work behind the scenes, you may find it easier to understand your firmware user interface's representation of that.

Configuring the boot process (from an operating system)

As we've noted above, unlike in the BIOS world, you can actually configure the UEFI boot process from the operating system level. If you have an insane firmware, you may ont to do this in order to achieve what you want.

You can use the efibootmgr tool mentioned earlier to add, delete and modify entries in the UEFI boot manager configuration, and actually do quite a lot of other stuff with it too. You can change the boot order. You can tell it to boot some particular entry in the list on the next boot, instead of using the BootOrder list (if you or some other tool has configured this to happen, your efibootmgr -v output will include a BootNext item stating which menu entry will be loaded on the next boot). There are tools for Windows that can do this stuff from Windows, too. So if you're really struggling to manage to do whatever it is you want to do with UEFI boot configuration from your firmware interface, but you pouvez boot a UEFI native operating system of some kind, you may want to consider doing your boot configuration from that operating system rather than from the firmware UI.

So to recap:

• Your UEFI firmware contains something very like what you think of as a boot menu.
• You can query its configuration with efibootmgr -v, from any UEFI-native boot of a Linux OS, and also monnaie its configuration with efibootmgr (see the man page for details).
• This 'boot menu' can contain entries that say 'boot this disk in BIOS compatibility mode', 'boot this disk in UEFI native mode via the fallback path' (which will use the 'look for BOOT(something).EFI' method described above), or 'boot the specific EFI format executable at this specific location (almost always on an EFI system partition)'.
• The nice, clean design that the UEFI spec is trying to imply is that all operating systems should install a bootloader of their own to an EFI system partition, add entries to this 'boot menu' that point to themselves, and butt out from trying to take control of booting anything else.
• Your firmware UI has free rein to represent this mechanism to you in whatever way it wants, and it may do this well, or it may do this poorly.

Installing operating systems to UEFI-based computers

Let's have a quick look at some specific consequences of the above that relate to installing operating systems on UEFI computers.

UEFI native and BIOS compatibility booting

Here's a very very simple one which people sometimes miss:

• If you boot the installation medium in 'UEFI native' mode, it will do a UEFI native install of the operating system: it will try to write an EFI-format bootloader to an EFI system partition, and attempt to add an entry to the UEFI boot manager 'boot menu' which loads that bootloader.
• If you boot the installation medium in 'BIOS compatibility' mode, it will do a BIOS compatible install of the operating system: it will try to write an MBR-type bootloader to the magic MBR space on a disk.

This applies (with one minor caveat I'm going to paper over for now) to all OSes of which I'm aware. So you probably want to make sure you understand how, in your firmware, you can choose to boot a removable device in UEFI native mode and how you can choose to boot it in BIOS compatibility mode, and make sure you pick whichever one you actually want to use for your installation.

You really cannot do a completely successful UEFI-native installation of an OS if you boot its installation medium in BIOS compatibility mode, because the installer will not be able to configure the UEFI boot manager (this is only possible when booted UEFI-native).

It is theoretically possible for an OS installer to install the OS in the BIOS style – that is, write a bootloader to a disk's MBR – after being booted in UEFI native mode, but most of them won't do this, and that's probably sensible.

Finding out which mode you're booted in

It is possible that you might find yourself with your operating system installer booted, and not sure whether it's actually booted in UEFI native mode or BIOS compatibility mode. Don't panic! It's pretty easy to find out which, in a few different ways. One of the easiest is just to try and talk to the UEFI boot manager. If what you have booted is a Linux installer or environment, and you can get to a shell (ctrl-alt-f2 in the Fedora installer, for instance), run efibootmgr -v. If you're booted in UEFI native mode, you'll get your UEFI boot manager configuration, as shown above. If you're booted in BIOS compatibility mode, you'll get something like this:

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.

If you've booted some other operating system, you can try running a utility native to that OS which tries to talk to the UEFI boot manager, and see if you get sensible output or a similar kind of error. Or you can examine the system logs and search for 'efi' and/or 'uefi', and you'll probably find some kind of indication.

Enabling UEFI native boot

To be bootable in UEFI native mode, your OS installation medium must obviously actually comply with all this stuff we've just described: it's got to have a GPT partition table, and an EFI system partition with a bootloader in the correct 'fallback' path – EFIBOOTBOOTx64.EFI (or the other names for the other platforms). If you're having trouble doing a UEFI native boot of your installation medium and can't figure out why, check that this is actually the case. Notably, when using the livecd-iso-to-disk tool to write a Fedora image to a USB stick, you must pass the --efi parameter to configure the stick to be UEFI bootable.

Forcing BIOS compatibility boot

If your firmware seems to make it very difficult to boot from a removable medium in BIOS compatibility mode, but you really want to do that, there's a handy trick you can use: just make the medium not UEFI native bootable at all. You can do this pretty easily by just wiping all the EFI system partitions. (Alternatively, if using livecd-iso-to-disk to create a USB stick from a Fedora image, you can just leave out the --efi parameter and it won't be UEFI bootable). If at that point your firmware refuses to boot it in BIOS compatibility mode, commence swearing at your firmware vendor (if you didn't already).

Disk formats (MBR vs. GPT)

Here's another very important consideration:

• If you want to do a 'BIOS compatibility' type installation, you probably want to install to an MBR formatted disk.
• If you want to do a UEFI native installation, you probably want to install to a GPT formatted disk.

Of course, to make life complicated, many firmwares pouvez boot BIOS-style from a GPT formatted disk. UEFI firmwares are in fact technically obligatoire to be able to boot UEFI-style from an MBR formatted disk (though we are not particularly confident that they all really can). But you really should avoid this if at all possible. This consideration is quite important, as it's one that trips up quite a few people. For instance, it's a bad idea to boot an OS installer in UEFI native mode and then attempt to install to an MBR formatted disk without reformatting it. This is very likely to fail. Most modern OS installers will automatically reformat the disk in the correct format if you allow them to completely wipe it, but if you try and tell the installer 'do a UEFI native installation to this MBR formatted disk and don't reformat it because it has data on it that I care about', it's very likely to fail, even though this configuration is technically covered in the UEFI specification. Specifically, Windows and Fedora at least explicitly disallow this configuration.

Checking the disk format

You can use the parted utility to check the format of a given disk:

[adamw@adam Downloads]$ sudo parted /dev/sda
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: ATA C300-CTFDDAC128M (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  525MB  524MB  primary  ext4         boot
 2      525MB   128GB  128GB  primary               lvm

(parted)      

See that Partition table: msdos? This is an MBR/MS-DOS formatted disk. If it was GPT-formatted, that would say gpt. You can reformat the disk with the other type of partition table by doing mklabel gpt ou mklabel msdos from within parted. This will destroy the contents of the disk.

With most OS installers, if you pick a disk configuration that blows away the entire contents of the target disk, the installer will automatically reformat it using the most appropriate configuration for the type of installation you're doing, but if you want to use an existing disk without reformatting it, you're going to have to check how it's formatted and take this into account.

Handling EFI system partition if doing manual partitioning

I can only give authoritative advice for Fedora here, but the gist may be useful for other distros / OSes.

If you allow Fedora to handle partitioning for you when doing a UEFI native installation – and you use a GPT-formatted disk, or allow it to reformat the disk (by deleting all existing partitions) – it will handle the EFI system partition stuff for you.

If you use custom partitioning, though, it will expect you to provide an EFI system partition for the installer to use. If you don't do this, the installer will complain (with a somewhat confusing error message) and refuse to let you start the installation.

So if you're doing a UEFI native install and using custom partitioning, you need to ensure that a partition of the 'EFI system partition' type is mounted at /boot/efi – this is where Fedora expects to find the EFI system partition it's using. If there is an existing EFI system partition on the system, just set its mount point to /boot/efi. If there is not an EFI system partition yet, create a partition, set its type to EFI system partition, make it at least 200MB big (500MB is good), and set its mount point to /boot/efi.

A specific example

To boil down the above: if you bought a Windows 8 or later system, you presque certainly have a UEFI native install of Windows to a GPT-formatted disk. This means that if you want to install another OS alongside that Windows install, you almost certainly want to do a UEFI-native installation of your other OS. If you don't like all this UEFI nonsense and want to go back to the good old world you're familiar with, you will, I'm afraid, have to blow away the UEFI-native Windows installation, and it would be a good idea to reformat the disk to MBR.

Implications and Complications

So, that's how UEFI booting works, at least a reasonable approximation. When I describe it like that, it almost all makes sense, right?

However, all is not sweetness and light. There are problems. There always are.

Attentive readers may have noticed that I've talked about the UEFI spec providing a mechanism. This is accurate, and important. As the UEFI spec is a 'broad consensus' sort of thing, one of its major shortcomings (looked at from a particular perspective) is that it's nowhere near prescriptive enough.

If you read the UEFI spec critically, its basic approach is to define a set of functions that UEFI compliant firmwares must support. What it doesn't do a lot of at all is strictly requiring things to be done in any particular way, or not done in any particular way.

So: the spec says that a system firmware must do all the stuff I've described above, in order to be considered a UEFI-compliant firmware. The spec, however, doesn't talk about what operating systems 'should' or 'must' do at all, and it doesn't say that firmwares must not support (or no-one may expect them to support, or whatever)…anything at all. If you're making a UEFI firmware, in other words, you have to support GPT formatted disks, and FAT-formatted EFI system partitions, and you must read UEFI boot manager entries in the standard format, and you must do this and that and the other – but you can also do any autre crap you like.

It's pretty easy to read certain implications from the spec – it carefully sets up this nice mechanism for handling OS (or other 'bootable thing') selection at the firmware level, for instance, with the clear implication "hey, it'd be great if all OSes were written to this mechanism". But the UEFI spec doesn't require that, and neither does any other widely-respected specification.

So, what happens in the real world is that we wind up with really dumb crap. Apple, for instance, ships at least certains Macs with their bootloaders in an HFS+ partition. The spec says a UEFI-compliant firmware must support UEFI FAT partitions with the specific GPT partition type that identifies them as an "EFI system partition", but it doesn't say the firmware can't aussi recognize some other filesystem type and load a bootloader from that. (Whether you consider such a partition to be an "EFI system partition" or not is an interesting philosophical conundrum, but let's skate right over that for now).

The world would pretty clearly be a better place if everyone just damn well used the EFI system partition format the spec goes to such great pains to define, but Apple is Apple and we can't have nice things, so Apple went right ahead and wrote firmwares that aussi can read and load code from HFS+ partitions, and now everyone else has to deal with that or tell Macs to go and get boned. Apple also goes quite a long way beyond the spec in its boot process design, and if you want your alternative OS to show up on its graphical boot menu with a nice icon and things, you have to do more than what the UEFI spec would suggest.

There are various similar incredibly annoying corner cases we've come across, but let's not go into them all right now. This post is long enough.

Also, as we noted earlier, the spec makes no requirements as to how the mechanism should be represented to the user. So if a couple of software companies write OSes to behave 'nicely' according to the conventions the spec is clearly designed to back, and install EFI boot loaders and define EFI boot manager entries with nice clear names – like, oh say, "Fedora" and "Windows" – they are implicitly relying on the firmware to then give the user certains kind of sane interface somewhere relatively discoverable that lets them choose to boot "Windows" or "Fedora". The more firmwares don't do a good job of this, the less willing OS engineers will be to rely on the 'proper' conventions, and the more likely they'll be to start rebuilding ugly hacks above the firmware level.

To be fair, we could do somewhat more at the OS level. We could present all those neat efibootmgr capabilities rather more obviously – we can use that 'don't respect BootOrder on the next boot, but instead boot this' capability, for instance, and have 'Reboot to Windows' as an option. It'd be kinda nice if someone looked at exposing all this functionality somewhere more obvious than efibootmgr. Windows 8 systems do use this, to some extent – you can reboot your system to the firmware UI from the Windows 8 settings menus, for instance. But still.

All this is really incredibly frustrating, because UEFI is so close to making things really a lot better. The BIOS approach doesn't provide any kind of convention or standard for multibooting at all – it has to be handled entirely above the firmware level. We (the industry) could have come up with some sort of convention for handling multiboot, but we never did, so it just became a multiple-decade epic fail, where each operating system came up with its own approach and lots of people wrote their own bootloaders which tried to subsume all the operating systems and all the operating systems and independent bootloaders merrily fought like cats in a sack. I mean, pre-UEFI multibooting is such a clusterf**k it's not even worth going into, it's broken sixteen ways from Sunday by definition.

If UEFI – or a spec built on top of it – had just mandated that everybody follow the conventions UEFI carefully establishes, and mandated that firmwares provide a sensible user interface, the win would have been epic. But it doesn't, so it's entirely possible that in a UEFI world things will be even worse than they were in the BIOS world. If many more firmwares show up that don't present a good UI for the UEFI boot manager mechanism, what could happen is that OS vendors give up on the UEFI boot manager mechanism (or decide to support it et alternatives, because choice!) and just reinvent the entire goddamn nightmare of BIOS multibooting on top of UEFI – and we'll all have to deal with all of that, plus the added complication of the UEFI boot manager layer. You'll have multiple bootloaders fighting to load multiple operating systems all on top of the whole UEFI boot manager mechanism which is just throwing a whole bunch of other variables into the equation.

This is not a prospect filling the mind of anyone who's had to think about it with joy.

Still, it's important to recognize that the sins of UEFI in this area are sins of omission – they are not sins of commission, and they're not really the result of evil intent on anyone's part. The entity you should really be angry with if you have an idiotic system firmware that doesn't give you good access to the UEFI boot manager mechanism is not the UEFI forum, or Microsoft, and it certainly isn't Fedora and even more certainly isn't me ;). The entity you should be angry at is your system/motherboard manufacturer and the goddamn incompetents they hired to write the firmware, because the UEFI spec makes it really damn clear to anyone with two brain cells to rub together that it would be a very good idea to provide some kind of useful user interface to the UEFI boot manager, and any firmware which doesn't do so is crap code by definition. Yes, the UEFI forum should've realized that firmware engineers couldn't code their way out of a goddamned paper bag and just ordered them to do so, but still, it's ultimately the firmware engineers who should be lined up against the nearest wall.

Wait, we can simplify that. "Any firmware is crap code". Usually pretty accurate.

Secure Boot

So now we come, finally, to Secure Boot.

Secure Boot is not magic. It's not complicated. OK, that's a lie, it's incredibly complicated, but the theory isn't very complicated. And no, Secure Boot itself is not evil. I am entirely comfortable stating this as a fact, and you should be too, unless you think GPG is evil.

Secure Boot is defined in chapter 28 of the UEFI spec (2.4a, anyway). It's actually a pretty clever mechanism. But what it does can be described very, very simply. It says that the firmware can contain a set of signatures, and refuse to run any EFI executable which is not signed with one of those signatures.

C'est ça. Well, no, it really isn't, but that's a reasonably acceptable simplification. Security is hard, so there are all kinds of wibbly bits to implementing a really secure bootchain using Secure Boot, and mjg59 can tell you all about them, or you can pour another large shot of gin and read the whole of chapter 28. But that's the basic idea.

Using public key cryptography to verify the integrity of something is hardly a radical or evil concept. Pretty much all Linux distributions depend on it – we sign our packages and have our package managers go AWOOGA AWOOGA if you try to install a package which isn't signed with one of our keys. This isn't us being evil, and I don't think anyone's ever accused an OS of being evil for using public key cryptographic signing to establish trust in this way. Secure Boot is literally this exact same perfectly widely accepted mechanism, applied to the boot chain. Yet because a bunch of journalists wildly grasped the wrong end of the stick, it's widely considered to be slightly more evil than Hitler.

Secure Boot, as defined in the UEFI spec, says nothing at all about what the keys the firmware trusts should be, or where they should come from. I'm not going to go into all the goddamn details, because it gets stultifyingly boring and this post is too long already. But the executive summary is that the spec is utterly and entirely about defining a mechanism for doing cryptographic verification of a boot chain. It does not really even consider any kind of icky questions about the policy for doing so. It does nothing evil. It is as flexible as it could reasonably be, and takes care to allow for all the mechanisms involved to be configurable at multiple levels. The word 'Microsoft' is not mentioned. It is not in any way, shape, or form a secret agenda for Microsoft's domination of the world. If you doubt this, at the very bloody least, go and read it. I've given you all the necessary pointers. There is literally not a single legitimate reason I can think of for anyone to be angry with the idea "hey, it'd be neat if there was a mechanism for optional cryptographic verification of bootloader code in this firmware specification". None. Not one.

Secure Boot in the real world

Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world.

The only one we really care about is Secure Boot as it's implemented on PCs shipped with Microsoft Windows 8 or higher pre-installed.

Microsoft has these things called the Windows Hardware Certification Requirements. There they are. They are not Top Secret, Eyes Only, You Will Be Fed To Bill Gates' Sharks After Reading – they're right there on the Internet for anyone to read.

If you want to get cheap volume licenses of Windows from Microsoft to pre-install on your computers and have a nice "reassuring" 'Microsoft Approved!' sticker or whatever on the case, you have to comply with these requirements. That's all the force they have: they are not actually a part of the law of the United States or any other country, whatever some people seem to believe. Bill Gates cannot feed you to his sharks if you sell a PC that doesn't comply with these requirements, so long as you don't want a cheap copy of Windows to pre-install and a nice sticker. There is literally no requirement for a PC sold à l'extérieur the Microsoft licensing program to configure Secure Boot in any particular way, or include Secure Boot at all. A PC that claims to have a UEFI 2.2 or later compliant firmware must implement Secure Boot, but can ship with it configured in literally absolutely any way it pleases (including turned off).

If you're going to have very loud opinions about Secure Boot, you have zero excuse for not going and reading the Microsoft certification requirements. Right now. I'll wait. You can search for "Secure Boot" to get to the relevant bit. It starts at "System.Fundamentals.Firmware.UEFISecureBoot".

You should read it. But here is a summary of what it says.

Computers complying with the requirements must:

• Ship with Secure Boot turned on (except for servers)
• Have Microsoft's key in the list of keys they trust
• Disable BIOS compatibility mode when Secure Boot is enabled (actually the UEFI spec requires this too, if I read it correctly)
• Support signature blacklisting

x86 computers complying with the requirements must additionally:

• Allow a physically present person to disable Secure Boot
• Allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts

ARM computers complying with the requirements must additionally:

• NOT allow a physically present person to disable Secure Boot
• NOT allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts

Oui. You read that correctly. The Microsoft certification requirements, for x86 machines, explicitly require implementers to give a physically present user complete control over Secure Boot – turn it off, or completely control the list of keys it trusts. Another important note here is that while the certification requirements state that the out-of-the-box list of trusted keys must include Microsoft's key, they don't say, for e.g., that it must not include any other keys. The requirements explicitly and intentionally allow for the system to ship with any number of other trusted keys, too.

These requirements aren't present entirely out of the goodness of Microsoft's heart, or anything – they're present in large part because other people explained to Microsoft that if they weren't present, it'd have a hell of a lawsuit on its hands² – but they are present. Anyone who actually understands UEFI and Secure Boot cannot possibly read the requirements any other way, they are extremely clear and unambiguous. They both clearly intend to et succeed in ensuring the owner of a certified system has complete control over Secure Boot.

If you have an x86 system that claims to be Windows certified but does not allow you to disable Secure Boot, it is in direct violation of the certification requirements, and you should certainly complain very loudly to someone. If a lot of these systems exist then we clearly have a problem and it might be time for that giant lawsuit, but so far I'm not aware of this being the case. All the x86-based, Windows-certified systems I've seen ont had the 'disable Secure Boot' option in their firmwares.

Now, for ARM machines, the requirements are significantly more evil: they state exactly the opposite, that it must not be possible to disable Secure Boot and it must not be possible for the system owner to change the trusted keys. This is bad and wrong. It makes Microsoft-certified ARM systems into a closed shop. But it's worth noting it's no Suite bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders.

If you're planning to buy a Microsoft-certified ARM device, be aware of this, and be aware that you will not be in control of what you can boot on it. If you don't like this, don't buy one. But also don't buy an iDevice, or an Android device with a locked bootloader (you can buy Android devices with unlocked or unlockable bootloaders, still, but you have to do your research).

As far as x86 devices go, though, right now, Microsoft's certification requirements actually explicitly protect your right to determine what can boot on your system. This is good.

Recommendations

The following are AdamW's General Recommendations On Managing System Boot, offered with absolutely no guarantees of accuracy, purity or safety.

• If you can possibly manage it, have one OS per computer. If you need more than one OS, buy more computers, or use virtualization. If you can do this everything is very simple and it doesn't much matter if you have BIOS or UEFI firmware, or use UEFI-native or BIOS-compatible boot on a UEFI system. Everything will be nice and easy and work. You will whistle as you work, and be kind to children and small animals. All will be sweetness and light. Really, do this.
• If you absolutely must have more than one OS per computer, at least have one OS per disk. If you're reasonably comfortable with how BIOS-style booting works and you don't think you need Secure Boot, it's pretty reasonable to use BIOS-compatible booting rather than UEFI-style booting in this situation on a UEFI-capable system. You'll probably have less pain to deal with and you won't really lose anything. With one OS per disk you can also mix UEFI-native and BIOS-compatible installations.
• If you absolutely insist on having more than one OS per disk, understand everything written on this page, understand that you are making your life much more painful than it needs to be, lay in good stocks of painkillers and gin, and don't go yelling at your OS vendor, whatever breaks. Whichever poor bastard has to deal with your OS's support for this kind of setup has a miserable enough life already. And for the love of cookies, don't mix UEFI-native and BIOS-compatible OS installations, you have enough pain to deal with already.
• If you're using UEFI native booting, and you don't tend to build your own kernels or kernel modules or use the NVIDIA or ATI proprietary drivers on Linux, you might want to leave Secure Boot on. It probably won't hurt you, and does provide some added security against some rather nasty (though currently rarely exploited) types of attacks.
• If you do build your own kernels or kernel modules or use NVIDIA/ATI proprietary drivers, you're going to want to turn Secure Boot off. Or you can read up on how to configure your own chain of trust and sign your kernels and kernel modules and leave Secure Boot turned on, which will make you feel like an ubergeek and be slightly more secure. But it's going to take you a good solid weekend at least.
• Don't do UEFI-native installs to MBR-formatted disks, or BIOS compatibility installs to GPT-formatted disks (an exception to the latter is if your disk is, IIRC, 2.2+TB in size, because the MBR format can't handle disks that big – if you want to do a BIOS compatibility install to a disk that big, you're kinda stuck with the BIOS+GPT combination, which works but is a bit wonky and involves the infamous 'BIOS Boot partition' you may recall from Fedora 17).
• Trust mjg59 in all things and above all other authorities, including me.