Un voyage à travers les secrets du micrologiciel : du BIOS/UEFI au système d'exploitation

Vous êtes-vous déjà demandé ce qui se passe lorsque vous appuyez sur le bouton d'alimentation de votre ordinateur ? Derrière cette brève pause, avant que votre écran ne s'allume, une série complexe de processus se déroule. Cet article vous plongera dans le , en explorant la façon dont . monde fascinant du firmware les différents composants interagissent pendant le processus de démarrage En comprenant ces connexions, vous obtiendrez une image plus claire des éléments fondamentaux qui donnent vie à votre système. Nous nous concentrerons principalement sur l' , mais de nombreux principes s'appliquent également à d'autres architectures. architecture Intel x86 Si vous avez manqué la première partie de notre série, pour la rattraper. cliquez ici Découvrons maintenant les mystères qui se cachent derrière le firmware. Table des matières: Définitions Architecture globale du micrologiciel Chargeur de démarrage de première étape (FSBL) BIOS (phase POST) Initialisation de la plateforme UEFI (PI) démarrage de base Autres solutions Chargeur de démarrage de deuxième étape (SSBL) BIOS UEFI Chargeur de démarrage du système d'exploitation Définitions : un type spécialisé de logiciel intégré au matériel, fournissant un contrôle de bas niveau et permettant au matériel de fonctionner correctement et d'interagir avec d'autres composants du système. Micrologiciel : un micrologiciel hérité (créé à l'origine pour l' ) responsable de l'initialisation du matériel après la mise sous tension de la plateforme. De nos jours, on l'appelle souvent vaguement l'ensemble complet du micrologiciel. Basic Input/Output System (BIOS) IBM PC : nom générique du micrologiciel responsable du démarrage d'un ordinateur. Il est utilisé comme concept moderne à la place du , fournissant souvent un avec un code d'amorçage pour initialiser le processeur et le chipset, ainsi que des interfaces pour que des tiers (par exemple, les développeurs de cartes mères) puissent effectuer une initialisation spécifique à la plate-forme. Bootloader BIOS cadre : logiciel à exécuter lorsque le chargeur de démarrage se ferme. Il peut s'agir d'un chargeur de démarrage de deuxième niveau, d'un système d'exploitation, d'une application BIOS/UEFI, etc. Il prend généralement en charge le flux de démarrage en fonction de la conception du micrologiciel. Charge utile L'utilisation des termes et peut prêter à confusion, car leurs significations dépendent du contexte. Cependant, lorsque quelqu'un mentionne , ou , il fait généralement référence à . BIOS bootloader firmware BIOS bootloader l'ensemble complet de firmwares exécutés entre le système d'exploitation et le matériel vs. : L'interface était la spécification d'origine développée par Intel. L' est le successeur de , créé par le pour normaliser et étendre la spécification d'origine. Dans la plupart des cas, et sont utilisés de manière interchangeable. EFI UEFI EFI (Extensible Firmware Interface) interface UEFI (Unified Extensible Firmware Interface) l'EFI Forum UEFI EFI UEFI Architecture globale du micrologiciel Pour comprendre comment les composants du firmware interagissent, nous allons explorer l'architecture entière avec toutes ses parties connectées. Le flux d'exécution, illustré dans le diagramme ci-dessous, démarre à partir du , qui fait partie du . À partir de là, il progresse à travers différentes étapes du firmware : vecteur de réinitialisation chargeur de démarrage de première étape Le firmware ou BIOS peut généralement être divisé en deux parties principales, avec une interface généralement minimale entre elles : : Responsable de l'initialisation des composants matériels du système. Initialisation du matériel : Fournit les interfaces nécessaires au système d'exploitation et à l'utilisateur. Interface avec le système d'exploitation et l'utilisateur La conception du micrologiciel de la plateforme peut être soit , combinant l'initialisation matérielle et la fonctionnalité de démarrage, soit suivre un et par étapes. Le choix de la conception dépend des exigences du système et peut être préférable pour certains appareils. monolithique flux de démarrage modulaire Le diagramme suivant illustre comment les différents composants du micrologiciel interagissent et peuvent être utilisés ensemble pour prendre en charge le processus de démarrage (les flèches indiquent la séquence d'exécution) : Si ces diagrammes vous semblent complexes maintenant, ne vous inquiétez pas. Relisez-les après avoir lu cet article et ils seront plus clairs. Chargeur de démarrage de première étape (FSBL) Ce micrologiciel est conçu pour initialiser les ordinateurs et les systèmes embarqués en : faire uniquement ce qui est absolument nécessaire, puis passer le contrôle au afin de démarrer le système d'exploitation. Le ne charge pas les systèmes d'exploitation à partir de supports de stockage autres que la . Comme il initialise uniquement le matériel sous-jacent et ne gère pas les supports de démarrage tels que les disques durs, les SSD ou les clés USB, un autre logiciel est nécessaire pour démarrer réellement un . mettant l'accent sur l'initialisation matérielle minimale chargeur de démarrage de deuxième étape FSBL puce flash système d'exploitation : Principales responsabilités de la FSBL : Passage du 16 bits au 32 bits ( : ou en dans le cas du BIOS). CPU mode réel mode protégé note mode virtuel 8086 : appel pour configurer pour l' Utilisation du cache de FSP-T le cache en tant que RAM environnement C. : initialisation du port de débogage configuré en appelant des méthodes d'initialisation spécifiques à la carte. Port de débogage : appel de pour initialiser la mémoire principale du système et enregistrer les informations cruciales de la mémoire système. Initialisation de la mémoire FSP-M : configuration des broches d'entrée/sortie à usage général (GPIO) pour l'interfaçage avec des périphériques externes. GPIO : Exécution d'une initialisation précoce de la plate-forme et utilisation pour terminer l'initialisation du chipset, du processeur et du contrôleur d'E/S. Silicium de FSP-S : énumération des périphériques PCI et allocation de ressources telles que les adresses mémoire et les IRQ. Énumération PCI : configuration des tables et , y compris les informations de préparation (tables coreboot, HOB) devant être transmises à la charge utile. Préparation de la charge utile SMBIOS ACPI : Chargement et transfert de contrôle à la charge utile. Chargement et transfert BIOS (Phase POST) Aux débuts de l'informatique, les logiciels open source n'étaient pas très populaires et la plupart des implémentations du BIOS étaient propriétaires. Il n'existe que quelques solutions open source disponibles fournissant le code source POST du BIOS, telles que et . Ces projets ont été conçus pour fonctionner sur les systèmes IBM 5150/5155/5160 et la plupart des clones XT. Super PC/Turbo XT BIOS GLaBIOS Cependant, les implémentations de BIOS open source les plus connues, comme et , n'effectuent pas d'initialisation matérielle car elles ne sont pas destinées à fonctionner sur du matériel nu. Mais elles sont largement utilisées comme et fonctionnent nativement dans des environnements virtuels comme QEMU et Bochs. OpenBIOS SeaBIOS chargeurs de démarrage de deuxième étape Quoi qu'il en soit, il y a peu de chances que vous ayez besoin de travailler directement avec ces premiers BIOS ou de vous plonger dans leurs spécificités. Mais si vous souhaitez les explorer, les référentiels mentionnés sont un bon point de départ. En ce qui concerne les tendances actuelles de développement, il ne semble pas y avoir de développement continu de solutions BIOS propriétaires, et de tels projets sont devenus obsolètes face aux alternatives modernes. Initialisation de la plateforme UEFI (PI) Le processus de démarrage suit un flux par étapes, commençant de la gauche vers la droite dans la figure suivante. La chronologie du processus de démarrage de la plateforme est divisée en plusieurs phases, comme indiqué par des cases jaunes : : Première phase après un , sa fonction principale est de configurer la RAM temporaire (CPU ou SRAM). Sécurité (SEC) vecteur de réinitialisation Cache-As-RAM : cette phase envoie des pilotes spécialisés appelés . Ces modules gèrent l'initialisation matérielle essentielle, comme la configuration du processeur et du chipset et la configuration . Initialisation pré-EFI (PEI) modules d'initialisation pré-EFI (PEIM) de la mémoire principale (DRAM) : dans cette phase, le reste de l'initialisation du système est effectué. La phase DXE fournit et prend en charge divers protocoles et pilotes nécessaires au fonctionnement du système. Environnement d'exécution du pilote (DXE) des services UEFI : cette phase implémente la politique de démarrage de la plateforme, en déterminant la séquence de démarrage et en sélectionnant le périphérique de démarrage/chargeur approprié. Sélection du périphérique de démarrage (BDS) : pendant cette phase, le système exécute des applications à l'aide des services UEFI pour préparer le système d'exploitation. Elle comprend la transition de l'environnement UEFI vers le système d'exploitation, qui se termine par l'appel . Chargement système transitoire (TSL) ExitBootServices() : Dans cette phase, le système d'exploitation est pleinement opérationnel, gérant le système sous son contrôle. Run Time (RT) : cette phase traite des scénarios dans lesquels le matériel ou le système d'exploitation tombe en panne/s'arrête/redémarre. Le micrologiciel peut tenter des actions de récupération, cependant, la spécification UEFI PI ne définit pas d'exigences ou de comportements spécifiques pour cette phase. After Life (AL) Ce processus et ses phases d'exécution sont couverts par la . Cependant, il existe également l' (indiquée par la ligne bleue en gras sur l'image), qui ne fait pas partie du document précédent et est décrite dans la . Bien que les noms et l'utilisation fréquente de puissent prêter à confusion, ces deux documents ont des objectifs différents : spécification UEFI Platform Initialization (PI) interface UEFI spécification UEFI l'UEFI : se concentre sur les interfaces entre les composants du micrologiciel de bas niveau et détaille la manière dont ces modules interagissent pour initialiser la plate-forme. Spécification UEFI PI : définit les interfaces d'interaction entre le système d'exploitation (OS) et le micrologiciel. Ce point sera abordé plus en détail dans le contexte du . Notez que la spécification UEFI s'appuie sur la spécification PI. Spécification UEFI chargeur de démarrage de deuxième étape En fait, les deux spécifications concernent les interfaces, mais à des niveaux différents. Pour des informations détaillées, vous pouvez accéder aux deux spécifications sur le . site Web du Forum UEFI a été initialement conçu comme une solution de micrologiciel unifiée, sans tenir compte de la distinction entre les chargeurs de démarrage de première et de deuxième étape. Cependant, lorsque nous faisons référence à comme , cela inclut les phases , et . La raison pour laquelle nous divisons DXE en étapes et est due à leurs rôles différents dans le processus d'initialisation. L'UEFI PI l'UEFI chargeur de démarrage de première étape SEC PEI DXE précoce précoces tardives Au cours de la phase , les pilotes effectuent généralement l'initialisation essentielle du processeur/du PCH/de la carte et génèrent également , qui aident à isoler la phase DXE du matériel spécifique à la plateforme. encapsulent les détails spécifiques à la plateforme, permettant à la phase de fonctionner indépendamment des spécificités matérielles. DXE initiale des protocoles d'architecture DXE (AP) Les AP DXE tardive Démarrage de base Des articles détaillés sur le fonctionnement de Coreboot seront bientôt disponibles. Suivez-moi sur les réseaux sociaux – ils seront publiés très bientôt ! Autres solutions : chargeur de démarrage de première étape qui assure uniquement l'initialisation des composants matériels de base, suivi du chargement de la charge utile. Cependant, il et ne prend pas en charge les architectures AMD x86 ou autres. Intel Slim Bootloader (SBL) ne fonctionne que sur les plates-formes Intel x86 : à la fois un chargeur de démarrage de première et de deuxième étape. Cependant, la prise en charge du démarrage direct à partir du x86 de la plateforme (connu sous le nom de mode nu) est limitée par rapport aux autres micrologiciels. Il est plus populaire sur les systèmes embarqués et les appareils basés sur ARM. En tant que chargeur de démarrage de deuxième étape, U-Boot implémente un mais se concentre sur les systèmes embarqués. Le U-Boot vecteur de réinitialisation sous-ensemble de l'UEFI Chargeur de démarrage de deuxième étape (SSBL) Une fois la configuration matérielle initiale terminée, la entre en jeu. Son rôle principal est de mettre en place une , garantissant que le système d'exploitation peut gérer les ressources système et interagir avec les composants matériels. deuxième étape interface logicielle entre le système d'exploitation et le micrologiciel de la plateforme Le vise à , en simplifiant le développement du système d'exploitation et des applications en gérant la plupart des interfaces au niveau matériel. Cette abstraction permet aux développeurs de se concentrer sur les fonctionnalités de niveau supérieur sans se soucier des différences matérielles sous-jacentes. SSBL masquer autant que possible les variations matérielles : Principales responsabilités de SSBL : obtient des informations spécifiques à la plate-forme à partir du , y compris le mappage de mémoire, le SMBIOS, les tables ACPI, le flash SPI, etc. Récupération des informations de la plate-forme chargeur de démarrage de première étape : inclut des pilotes pour SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, interfaces réseau, etc. Exécutez des pilotes indépendants de la plate-forme : fournit un ensemble de services qui facilitent la communication entre le système d'exploitation et les composants matériels. Implémentation de services (également appelée interface) : propose un menu de configuration pour la configuration du système, permettant aux utilisateurs d'ajuster les paramètres liés à l'ordre de démarrage, aux préférences matérielles et à d'autres paramètres système. Menu de configuration : mécanisme permettant de localiser et de charger la charge utile (probablement le système d'exploitation) à partir du support de démarrage disponible. Logique de démarrage BIOS L'interface du BIOS est connue sous le nom . Ces fonctions fournissent un ensemble de routines pour l'accès au matériel, mais les détails spécifiques de la manière dont elles sont exécutées sur le matériel particulier du système sont cachés à l'utilisateur. de services/fonctions/appels d'interruption du BIOS En 16 bits, ils sont facilement accessibles en invoquant une interruption logicielle via l'instruction du langage assembleur x86. En 32 bits, presque tous les services du BIOS ne sont pas disponibles en raison de la manière différente dont les valeurs sont gérées. mode réel INT mode protégé de segment Prenons par exemple ( ), qui fournit des services de lecture et d'écriture de disque dur et de disquette basés sur des secteurs en utilisant l'adressage , comme exemple de la façon dont cette interface peut être utilisée. Supposons que nous souhaitons lire 2 secteurs (1024 octets) et les charger à l'adresse mémoire , le code suivant pourrait alors être exécuté : Disk Services INT 13h CHS (Cylindres-têtes-secteurs) 0x9020 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code Si vous êtes intéressé par la manière dont ce service est écrit dans SeaBios, jetez un œil à . src/disk.c Phase de démarrage Commence à rechercher un (il peut s'agir d'un disque dur, d'un CD-ROM, d'une disquette, etc.) en lisant le (secteur zéro) des périphériques. périphérique de démarrage premier secteur de 512 octets La séquence d'amorçage dans le BIOS charge le premier valide qu'il trouve dans la mémoire physique de l'ordinateur à l'adresse (indice : et font référence à la même adresse physique). Master Boot Record (MBR) physique 0x7C00 0x0000:0x7c00 0x7c0:0x0000 Le BIOS transfère le contrôle aux de la charge utile. Ce , qui est trop petit pour contenir l'intégralité du code de la charge utile, sert à charger le reste de la charge utile à partir du . À ce stade, la charge utile peut utiliser l'interface exposée par le BIOS. 512 premiers octets secteur chargé périphérique de démarrage Il est intéressant de noter que à l'origine. Le BIOS est une : il fonctionne de la même manière que sur les PC IBM réels, dans les années 1980. Les autres fabricants ont simplement et ont créé des BIOS compatibles IBM. Par conséquent, il n'y avait aucune réglementation pour empêcher les fabricants de BIOS d'inventer de nouvelles fonctions du BIOS ou d'avoir des fonctionnalités qui se chevauchent. les spécifications du BIOS n'existaient pas norme de fait procédé à une rétro-ingénierie Interface de micrologiciel extensible unifiée (UEFI) Comme mentionné précédemment, l'UEFI n'est qu'une spécification et possède de nombreuses implémentations. La plus utilisée est , une open source des spécifications UEFI et PI. Bien qu'EDKII seul ne soit pas suffisant pour créer un micrologiciel de démarrage entièrement fonctionnel, il fournit une base solide pour la plupart des solutions commerciales. TianoCore EDK II implémentation de référence Pour prendre en charge différents et fournir une interface UEFI, le projet est utilisé. Il s'appuie sur la configuration initiale effectuée et sur les informations de plate-forme fournies par le micrologiciel de démarrage pour préparer le système à l'environnement UEFI. chargeurs de démarrage de première étape UEFI Payload La charge utile UEFI utilise les phases et , qui sont conçues pour être indépendantes de la plateforme. Elle offre une charge utile générique qui peut s'adapter à différentes plateformes. Dans la plupart des cas, elle ne nécessite aucune personnalisation ni aucun ajustement spécifique à la plateforme et peut être utilisée telle quelle en consommant les informations de la plateforme à partir du . DXE BDS chargeur de démarrage de première étape : Variantes de la charge utile UEFI : nécessite une bibliothèque d'analyse pour extraire les informations de plateforme spécifiques à l'implémentation nécessaires. Si le chargeur de démarrage met à jour son API, la charge utile doit également être mise à jour. Charge utile UEFI héritée : conforme à la , en utilisant ou comme format d'image commun. Au lieu de les analyser lui-même, il s'attend à recevoir les à l'entrée de la charge utile. Charge utile UEFI universelle spécification USF (Universal Scalable Firmware) le format ELF (Executable and Linkable Format) le format FIT (Flat Image Tree) blocs de transfert (HOB) Bien que la fonctionne bien, la communauté EDK2 tente de faire évoluer l'industrie vers la . Le choix entre les charges utiles dépend des composants de votre firmware. Par exemple, il n'est pas possible d'exécuter la sur sans . D'un autre côté, l'utilisation de avec coreboot nécessite une couche de calage pour traduire en , une fonctionnalité uniquement disponible dans le . charge utile UEFI Legacy charge utile UEFI universelle charge utile Legacy avec prise en charge SMM Slim Bootloader mon patch la charge utile universelle les tables coreboot HOB fork StarLabs EDK2 Interface Chaque système compatible UEFI fournit une qui est transmise à chaque code exécuté dans l'environnement UEFI (pilotes, applications, chargeurs de système d'exploitation). Cette structure de données permet à un exécutable UEFI d'accéder telles que , et un ensemble de . table système aux tables de configuration système ACPI SMBIOS services UEFI La structure de la table est décrite dans : MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; Les services incluent les types suivants : , et . services de démarrage services d’exécution services fournis par des protocoles L'UEFI abstrait l'accès au périphérique en configurant . Ces et sont identifiés par un qui permet aux autres modules de les localiser et de les utiliser. Ils peuvent être découverts via les services de démarrage. des protocoles UEFI protocoles sont des structures de données contenant des pointeurs de fonction identifiant unique global (GUID) Un génère ces protocoles, et les fonctions réelles (pas les pointeurs !) sont contenues dans le pilote lui-même. Ce mécanisme permet aux différents composants de l'environnement UEFI de communiquer entre eux et garantit que le système d'exploitation peut interagir avec les périphériques avant de charger ses propres pilotes. pilote UEFI Alors que certains protocoles sont prédéfinis et décrits dans la spécification UEFI, les fournisseurs de micrologiciels peuvent également pour étendre les fonctionnalités d'une plate-forme. créer leurs propres protocoles personnalisés Services de démarrage Fournit des fonctions qui ne peuvent être utilisées démarrage. Ces services restent disponibles jusqu'à ce que la fonction soit appelée ( ). qu'au EFI_BOOT_SERVICES.ExitBootServices() MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c Les pointeurs vers tous les services de démarrage sont stockés dans la ( ) : table des services de démarrage MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES; Services d'exécution Un ensemble minimal de services reste accessible pendant l'exécution du système d'exploitation. Contrairement aux services de démarrage, ces services restent valides après qu'une charge utile (par exemple, le chargeur de démarrage du système d'exploitation) a pris le contrôle de la plateforme via un appel à . EFI_BOOT_SERVICES.ExitBootServices() Les pointeurs vers tous les services d'exécution sont stockés dans ( ) : la table des services d'exécution MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES; L'image ci-dessous montre la chronologie des services de démarrage et d'exécution, afin que vous puissiez voir exactement quand chacun d'eux est actif. Phase de sélection du périphérique de démarrage (BDS) La spécification UEFI définit un moteur de stratégie de démarrage appelé . Il tentera de charger dans un ordre spécifique. Cet ordre et d'autres paramètres peuvent être configurés en modifiant globales. Examinons les plus importantes d'entre elles : gestionnaire de démarrage UEFI les applications UEFI les variables NVRAM (mémoire vive non volatile) ( est remplacé par une valeur hexadécimale unique) — une option de démarrage/chargement. Boot#### #### — l'option de démarrage utilisée pour démarrer le système en cours d'exécution. BootCurrent — l'option de démarrage pour le prochain démarrage uniquement. Elle remplace pour un seul démarrage et est supprimée par le gestionnaire de démarrage après la première utilisation. Cela vous permet de modifier le comportement du prochain démarrage sans modifier . BootNext BootOrder BootOrder — la liste de chargement des options de démarrage ordonnées. Le gestionnaire de démarrage essaie de démarrer la première option active de cette liste. En cas d'échec, il essaie l'option suivante, et ainsi de suite. BootOrder — les types d’options de démarrage pris en charge par le gestionnaire de démarrage. BootOptionSupport — le délai d'expiration des gestionnaires de démarrage du micrologiciel, en secondes, avant de choisir automatiquement la valeur de démarrage parmi ou . Timeout BootNext BootOrder Ces variables peuvent être facilement obtenues à partir de Linux en utilisant : efibootmgr(8) [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Examinons le démarrage en nous appuyant sur l'extrait de code ci-dessus. UEFI va commencer à parcourir la liste . Pour chaque entrée de la liste, il recherche une variable correspondante : pour 0000, pour 2003, etc. Si la variable n'existe pas, il passe à l'entrée suivante. Si la variable existe, il lit le contenu de la variable. Chaque variable d'option de démarrage contient un descripteur qui est un tampon rempli d'octets de champs de longueur variable (il s'agit simplement de la structure de données). BootOrder Boot#### Boot0000 Boot2003 EFI_LOAD_OPTION La structure des données est décrite dans [MdePkg/Include/Uefi/UefiSpec.h][ ) https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION; À ce stade, le micrologiciel examinera un ( ). Dans la plupart des cas, notre ordinateur est démarré à partir d'un périphérique de stockage (disque dur/SSD/NVMe/etc.). Ainsi, le contiendrait le nœud . chemin d'accès au périphérique EFI_DEVICE_PATH_PROTOCOL chemin d'accès au périphérique HD(Partition Number, Type, Signature, Start sector, Size in sectors) — indique le format utilisé pour le schéma de partitionnement avec les mots-clés (1) ou (2). Type MBR GPT — une signature MBR de 4 octets si le type est , ou un de 16 octets si le type est . Signature MBR UUID GPT : si vous souhaitez savoir comment traduire d'autres chemins, lisez . Remarque la spécification UEFI v2.10, 10.6.1.6 Référence du nœud de périphérique texte L'UEFI examinera le disque et verra s'il contient une partition correspondant au nœud. Si elle existe, elle doit être étiquetée avec un spécifique qui la marque comme . Celle-ci est formatée avec un système de fichiers dont la spécification est basée sur la version spécifique du et est nommée ; en fait, il s'agit simplement d'un normal. identifiant unique global (GUID) partition système EFI (ESP) système de fichiers FAT Système de fichiers EFI FAT12/16/32 : si le contient un chemin explicite vers le fichier , alors UEFI recherchera ce fichier spécifique. Par exemple, l'option contient . Démarrage natif chemin d'accès du périphérique File(\Path\To\The\File.efi) Boot0000 File(\EFI\ARCHLINUX\grubx64.efi) : si le pointe simplement vers un disque, dans de telles situations, le micrologiciel utilisera un basé sur l'architecture — ( pour ou pour / ). Ce mécanisme permet au (par exemple, une clé USB) de fonctionner en UEFI ; ils utilisent simplement un . Par exemple, l'option utilisera ce mécanisme. Démarrage de secours chemin d'accès au périphérique chemin de démarrage de secours \EFI\BOOT\BOOT{arch}.EFI BOOTx64.EFI amd64 BOOTia32.EFI i386 IA32 support amovible de démarrage chemin de démarrage de secours Boot0002 toutes les options mentionnées ci-dessus font référence aux options de démarrage affichées dans l'exemple de sortie de . Remarque : Boot#### efibootmgr Dans les deux cas, le charge l' (il peut s'agir , du shell UEFI, d'un logiciel utilitaire, de la configuration du système, etc.) en mémoire. À ce moment, le contrôle est alors transféré au point d'entrée de l' . Contrairement , l' peut rendre le contrôle au micrologiciel (en dehors de la situation où l'application prend le contrôle du système). Si cela se produit ou si quelque chose ne va pas, le passe à l'entrée suivante et suit exactement le même processus. gestionnaire de démarrage UEFI application UEFI du chargeur de démarrage du système d'exploitation application UEFI au BIOS application UEFI gestionnaire de démarrage Boot#### La spécification mentionne que le peut gérer automatiquement les variables de la base de données. Cela inclut la suppression des variables d'option de chargement qui ne sont pas référencées ou qui ne peuvent pas être analysées. De plus, il peut réécrire n'importe quelle liste ordonnée pour supprimer toutes les options de chargement sans variables d'option de chargement correspondantes. gestionnaire de démarrage Le texte ci-dessus décrit le . De plus, le micrologiciel UEFI peut s'exécuter en mode qui émule un BIOS. démarrage UEFI Compatibility Support Module (CSM) Chargeur de démarrage du système d'exploitation Un logiciel démarré par le micrologiciel (généralement ) et utilisant son interface pour . Il peut être aussi complexe qu'un système d'exploitation et offrir des fonctionnalités telles que : le chargeur de démarrage de deuxième étape charger le noyau du système d'exploitation Lecture à partir de divers systèmes de fichiers (HFS+, ext4, XFS, etc.) Interagir sur un réseau (par exemple, TFTP, HTTP) Démarrage des noyaux compatibles Multiboot Chargement en chaîne Chargement des disques RAM initiaux ( ) initrd Et plus encore ! Les conceptions courantes de ces programmes dépassent le cadre de cet article. Pour une comparaison détaillée des chargeurs de démarrage de systèmes d'exploitation les plus courants, vous pouvez vous référer au et à l' . wiki ArchLinux article de Wikipédia Le système Windows utilise son propre chargeur de démarrage de système d'exploitation appelé . Windows Boot Manager (BOOTMGR) Le micrologiciel n'est plus un . Il est devenu une , et les tendances actuelles ne font qu'y contribuer. Nous pouvons exécuter , et bien d'autres applications intéressantes dessus. petit morceau de code complexe énorme quantité de code complexe Doom Twitter Comprendre l'architecture globale permet d'organiser ces composants dans votre esprit. En examinant la conception du micrologiciel existant, vous obtenez un aperçu du processus fascinant qui se déroule à chaque mise sous tension d'un ordinateur. Cette perspective descendante clarifie non seulement le rôle de chaque élément, mais met également en évidence la nature sophistiquée et évolutive des systèmes de micrologiciels modernes. Ressources Spécification UEFI version 2.10 Spécification d'initialisation de la plateforme UEFI version 1.8 (Errata A) Documentation EDK II Documentation du projet Slim Bootloader Démarrage UEFI : comment cela fonctionne-t-il réellement ? Comprendre le démarrage des plateformes modernes basées sur UEFI Anatomie de la séquence de démarrage UEFI sur Intel Galileo Note très simple sur les « chemins » des périphériques de disque dans certaines architectures courantes. Comment démarrent les ordinateurs