Auparavant, nous avons déjà analysé la séquence de démarrage du serveur en utilisant le Legacy Legacy comme exemple. Il est maintenant temps de mieux connaître l'UEFI.
La première version de ce qui est maintenant connu sous le nom d' UEFI (Unified Extensive Firmware Interface) a été développée dans les années 90 du dernier millénaire spécifiquement pour les systèmes Intel® Itanium® et s'appelait Intel Boot Initiative, puis EFI.
Le désir de «mettre à jour» le processus de démarrage était attendu. PC-BIOS , maintenant appelé Legacy, propose de travailler en mode réel 16 bits, n'adresse que 1 Mo de RAM, et le chargeur de démarrage ainsi que la table de partition doivent être situés dans les 512 premiers octets du lecteur. De plus, PC-BIOS transfère le contrôle au premier bootloader trouvé sans possibilité de revenir en arrière. Dans ce cas, la gestion des boîtiers avec plusieurs systèmes d'exploitation est placée sur les épaules du bootloader.
La limitation de la taille du chargeur de démarrage dicte l'utilisation du balisage MBR (Master Boot Record), apparu en 1983. Le MBR n'est pas standardisé, mais de nombreux fournisseurs sont «traditionnels». Le MBR a de sérieuses limitations: seules 4 partitions sont prises en charge par défaut et la capacité de stockage ne dépasse pas 2,2 To.
En décembre 2000, la première spécification EFI répandue a été publiée sous la version 1.02. Cinq ans plus tard, Intel a transféré EFI au Forum UEFI, ajoutant Unified au titre pour souligner le changement. La spécification UEFI est dans le domaine public et se compose de plusieurs documents:
- Spécification ACPI;
- Spécification UEFI;
- Spécification du shell UEFI;
- Spécification d'initialisation de la plate-forme UEFI;
- Spécification de l'empaquetage de distribution d'initialisation de plate-forme UEFI.
Le plaisir commence dans la spécification d'initialisation de la plate-forme UEFI , qui décrit toutes les phases de chargement de la plate-forme.
UEFI est universel, mais dans cet article nous nous appuierons sur le standard, en regardant vers les processeurs sur l'architecture x86_64.
RĂ©veille-toi, Neo!
fois la mise sous tension de la plate-forme lancée, le bloc d'alimentation attend la fin des transitoires, puis définit le signal sur la ligne Power_Good . Et le premier à commencer à fonctionner n'est pas le processeur central, mais le sous-système autonome Intel® Management Engine (ME) ou AMD Secure Technology (ST) similaire. Ce sous-système effectue ses propres opérations, puis prépare et lance le premier cœur d'un seul processeur, appelé Bootstrap Processor (BSP) .
Conformément à la terminologie acceptée, le thread cœur / processeur sera ci-après appelé processeur d'amorçage ou processeur d'application.Comme dans Legacy, le processeur commence à exécuter la première instruction à la fin de l'espace d'adressage à 0xFFFFFFF0 . Cette instruction est un saut vers la première phase d'initialisation de la plate-forme - SEC.
Phase SEC (sécurité)
Dans cette phase, les tâches suivantes doivent être résolues:
- gérer l'événement d'activation;
- initialiser suffisamment de mémoire pour la phase suivante;
- établir la racine de la confiance dans le système;
- transfert des informations nécessaires et contrôle à la phase suivante.
Les processeurs x86_64 démarrent en mode réel 16 bits et lors de l'initialisation initiale, le BSP est placé en mode protégé 32 bits . Ensuite, le microcode de tous les processeurs disponibles est mis à jour.
Vient ensuite le traitement de l'événement d'activation. Cela signifie l'agrégation d'informations sur l'état de l'équipement afin que dans la phase suivante, certains modules puissent tirer des conclusions sur la «santé» et l'état général de la plate-forme.
Pendant la phase SEC, aucune initialisation de la RAM ne se produit. Au lieu de cela, le cache du processeur gratuit est marqué comme non jetable et est converti en RAM temporaire. Ce mode est appelé mode sans éviction (NEM)... Une pile est créée dans la mémoire allouée, ce qui permettra aux modules des phases suivantes d'utiliser des langages de programmation de pile avant d'initialiser la RAM principale.
En outre, tous les processeurs d'application (Processeurs d'application, AP) sont initialisés avec une séquence spéciale d'interruptions inter-processeurs (Inter-Processor Interrupt, IPI) qui leur est envoyée. La séquence Init IPI - Start-up IPI - réveille le processeur d'application et lance l' autotest intégré (BIST) sur celui-ci . Les résultats des tests sont enregistrés et transmis pour analyse.
À la fin de la phase de sécurité, vous devez trouver la section Volume du micrologiciel de démarrage (BFV), sur lequel se trouve le code exécutable de la phase suivante, ainsi que, si possible, trouver d'autres sections mineures avec le code (Volume du micrologiciel, FV).
Pour justifier le nom de la phase de sécurité et devenir une racine de confiance, lors de l'exécution de cette phase, le code vers lequel nous prévoyons de transférer le contrôle peut être vérifié pour les modifications non autorisées et les parties malveillantes du programme.
A la fin de l'exécution SEC, les informations suivantes sont collectées:
- taille et adresse du volume du micrologiciel de démarrage (BFV);
- la taille et les adresses des autres volumes de micrologiciel (FV);
- taille et adresse de la RAM temporaire;
- la taille et l'adresse de la pile.
Ensuite, la prochaine Ă©tape commence - Avant l'initialisation EFI.
Phase PEI (Pre EFI Initialization)
L' objectif de la phase d'initialisation pré-EFI est de collecter des informations sur les périphériques connectés et de préparer la quantité minimale de matériel nécessaire pour démarrer le processus d'initialisation complet.
De par sa conception, la phase PEI doit être légère, car la mémoire cache du processeur est limitée. De plus, la phase PEI peut se remettre d'une panne, il est donc nécessaire de placer le code de phase PEI dans un stockage plus résilient.
Cette phase consiste en un noyau appelé PEI Foundation et les plugins PEI Module (PEIM) . La partie centrale du noyau est le gestionnaire de modules, PEI Dispatcher, qui contrôle l'ordre d'exécution des modules, et organise également les interactions inter-modules (PEIM-to-PEIM Interface, PPI).
Notez que la phase SEC a été exécutée à partir de la mémoire flash de la carte mère, et seulement au début de PEI, le code exécutable nécessaire à cette phase est copié dans la RAM temporaire.
Vient ensuite le répartiteur de l'Île-du-Prince-Édouard. Il lance les modules PEI dans un ordre spécifique: d'abord, des modules sans dépendances, puis dépendants du premier, et ainsi de suite jusqu'à épuisement des modules.
L'architecture de la phase PEI vous permet de développer vos propres modules qui peuvent transférer les résultats de leurs activités à la phase suivante. Le transfert d'informations s'effectue via une structure de données spéciale Hand-off Block (HOB) .
Lors du lancement des modules PEI, notez ce qui suit:
- CPU PEIM - initialisation du processeur;
- Plateforme PEIM - initialisation des ponts Nord (y compris Memory Controller Hub) et Sud (I / O Controller Hub);
- Initialisation de la mémoire PEIM - initialisation de la RAM principale et transfert des données de la mémoire temporaire vers la RAM.
Auparavant, l'inclusion était reçue de la phase SEC. Si l'événement de mise sous tension est S3 Resume , alors S3 BootScript est exécuté ensuite , ce qui restaure l'état enregistré des processeurs et de tous les périphériques connectés, puis transfère le contrôle directement au système d'exploitation.
L'état S3 (Suspend to RAM) est un état de veille dans lequel le processeur et une partie du chipset sont arrêtés avec une perte de contexte. Au réveil de cet état, le processeur commence à s'exécuter comme s'il s'agissait d'une mise sous tension normale. Mais au lieu d'une initialisation complète et de la réussite de tous les tests, le système se limite à restaurer l'état de tous les périphériques.Lorsqu'il est démarré à partir d'un autre état, le contrôle est transféré à la phase d'environnement d'exécution du pilote.
Phase DXE (Driver eXecution Environment)
Phase DXE Initialisation AHCI La phase DXE (Driver Execution Environment) se concentre sur l'initialisation des périphériques restants. Au moment où la phase DXE démarre, le processeur et la mémoire principale sont prêts à fonctionner et les pilotes DXE ne sont pas soumis à des limites de ressources strictes.
Semblable à la Fondation PEI, cette phase a son propre noyau - la Fondation DXE . Le noyau crée les interfaces nécessaires et charge trois types de services DXE:
- Services de démarrage UEFI - services de démarrage;
- Services d'exécution UEFI - services d' exécution ;
- Les services DXE sont des services spéciaux requis par le noyau DXE.
Une fois les services initialisés, le répartiteur DXE commence à fonctionner . Il trouve et charge les pilotes DXE, qui à leur tour complètent l'initialisation matérielle.
Dans UEFI, il n'y a pas de phase dédiée où le matériel passe le POST (Power-On Self-Test). Au lieu de cela, chaque module de phase PEI et DXE effectue son propre ensemble de tests et le communique via des codes POST à ​​l'utilisateur et via des HOB dans les phases suivantes.Parmi les nombreux pilotes chargés sur les processeurs x86_64, il convient de prêter attention au pilote System Management Mode Init (SMM Init). Ce pilote prépare tout pour que le mode de gestion système (SMM) fonctionne . SMM est un mode privilégié spécial qui vous permet de suspendre l'exécution du code actuel (y compris le système d'exploitation) et d'exécuter le programme à partir de la zone protégée de SMRAM dans son propre contexte.
SMM est officieusement considéré comme l' anneau de protection -2. Le noyau du système d'exploitation fonctionne sur l'anneau 0, et les anneaux de protection les plus restreints sont numérotés de 1 à 3. Officiellement, l'anneau zéro est considéré comme le plus privilégié. Cependant, un hyperviseur virtualisé par matériel est traditionnellement appelé anneau -1, et Intel ME et AMD ST sont appelés anneau -3.De plus, nous notons le module de prise en charge de la compatibilité (CSM) , qui garantit la compatibilité avec Legacy et vous permet de démarrer le système d'exploitation sans prise en charge UEFI. Nous examinerons ce module plus en détail plus tard.
Après avoir initialisé tous les équipements, il est temps de sélectionner un périphérique de démarrage.
Phase BDS (Boot Device Select)
La phase de sélection du périphérique de démarrage implémente la stratégie de démarrage de l'application UEFI. Bien qu'il s'agisse d'une phase distincte, tous les services, y compris le répartiteur, créés pendant la phase DXE restent disponibles.
Le but de la phase BDS est d'accomplir les tâches suivantes:
- initialisation des périphériques de console;
- recherchez les appareils à partir desquels vous pouvez démarrer;
- une tentative de démarrage à partir des périphériques trouvés par ordre de priorité.
carte d' extension LSI Le gestionnaire de démarrage recherche les zones amorçables sur les périphériques. Certaines cartes d'extension, telles que les cartes réseau et les contrôleurs RAID, peuvent avoir leur propre «BIOS» appelé Option ROM ou OpROM . Le contenu des périphériques OpROM est démarré immédiatement après la détection, et après l'exécution, le contrôle revient au gestionnaire de démarrage.
Toutes les partitions contenant des zones de téléchargement sont stockées dans la mémoire du gestionnaire de démarrage et sont classées selon l'ordre de démarrage. Si aucune application n'est trouvée, Boot Manager peut appeler le gestionnaire DXE, au cas où le gestionnaire aurait chargé des pilotes supplémentaires pendant la recherche et que de nouveaux périphériques pourraient «s'ouvrir» dans le gestionnaire de démarrage.
Comme indiqué précédemment, l'utilisation du balisage Master Boot Record impose des restrictions sur la taille des partitions et leur nombre sur le lecteur, et entraîne également certains inconvénients dans la maintenance de plusieurs systèmes d'exploitation. La solution à tous ces problèmes fait partie de la spécification UEFI - GUID Partition Table.
GPT (table de partition GUID)
La table de partition GUID est un format de table de partition standardisé qui remplace l'ancien MBR.
Premièrement, GPT utilise l'adressage de bloc logique (LBA) au lieu de l' adressage Cylindre, Tête, Secteur (CHS). La modification de la méthode d'adressage permet à GPT de fonctionner avec des lecteurs jusqu'à 9,4 ZB (9,4 * 10 21 octets) contre 2,2 To pour MBR.
Deuxièmement, la table de partition a subi des modifications et vous pouvez désormais créer jusqu'à 2 64 partitions sur un seul lecteur , bien que les systèmes d'exploitation ne prennent pas en charge plus de 128 dans le cas de Microsoft Windows et 256 dans le cas de Linux.
Troisièmement, chaque section a son propre identificateur de type, qui décrit le but de la section. Ainsi, par exemple, l'identifiant C12A7328-F81F-11D2-BA4B-00A0C93EC93B pointe de manière unique vers la partition système EFI (ESP) à partir de laquelle Boot Manager peut essayer de charger l'application.
Lors du développement de GPT, la compatibilité avec le MBR n'a pas été épargnée. Les utilitaires de disque peuvent ne pas reconnaître le disque GPT et le nettoyer. Pour éviter cela, lors du partitionnement GPT, les 512 premiers octets sont remplis avec Protective MBR (Protective MBR) - une partition d'une partition pour l'ensemble du lecteur avec l'identifiant système 0xEE. Cette approche permet à l'UEFI de comprendre qu'il ne s'agit pas d'un vrai MBR devant lui, mais d'un ancien logiciel sans support GPT - pour voir une partition avec des données d'un type inconnu.
GPT a abandonné la zone de démarrage au profit des partitions ESP reconnues comme amorçables. Boot Manager collecte des informations sur tous les ESP sur le disque, ce qui vous permet d'avoir plusieurs bootloaders sur le lecteur sans conflits, un pour chaque ESP.
Chargement du système d'exploitation
Après avoir interrogé tous les périphériques et recherché les zones de démarrage, Boot Manager démarre le démarrage dans l'ordre de priorité de démarrage. En général, le contrôle est transféré à l'application UEFI, qui commence à exécuter sa logique. Cependant, pour les systèmes compatibles avec le mode Legacy, il peut y avoir un MBR dans la liste de la zone de démarrage et vous devrez vous rendre dans le CSM, le module de support de compatibilité.
Le CSM vous permet d'exécuter des systèmes d'exploitation qui ne prennent pas en charge UEFI. Pour charger de tels systèmes d'exploitation, le module CSM émule l'environnement dans lequel s'inscrit le système d'exploitation "classique":
- charge le pilote Legacy;
- charge le BIOS hérité;
- met la sortie vidéo en mode compatible Legacy;
- Crée des structures de données requises pour Legacy en mémoire qui ne sont pas disponibles dans UEFI;
- charge le pilote CompatibilitySmm pour que SMM fonctionne dans Legacy.
Rappelez-vous qu'en mode Legacy, le système d'exploitation démarre en mode 16 bits, tandis qu'en UEFI tout fonctionne en mode 32 bits. CSM démarre le chargeur de démarrage hérité en mode 16 bits et fournit la communication avec les pilotes UEFI 32 bits si nécessaire.
Phase RT (temps de fonctionnement)
Le démarrage du démarrage du système d'exploitation ou du chargeur de démarrage hérité entraîne le début de la phase d'exécution. Pendant cette phase, tous les services DXE (à l'exception des services d'exécution UEFI) ne sont plus disponibles.
Le contenu de la phase RT peut varier. Il peut y avoir un chargeur de système d'exploitation familier de Legacy - par exemple, GRUB2 ou Windows Boot Manager, qui met le processeur en mode 64 bits et démarre le système d'exploitation. Mais il peut y avoir des applications indépendantes ou simplement le noyau du système d'exploitation.
Le noyau Linux à partir de la version 3.3, si l'indicateur CONFIG_EFI_STUB est présent, se transforme en une application UEFI standard et peut être lancé depuis UEFI sans utiliser de chargeurs de démarrage tiers.
Comme dans le cas du Legacy, le bootloader ou le noyau lui-même doit mettre le processeur en mode 64 bits, charger tous les pilotes, configurer le planificateur et exécuter init. Init, à son tour, lance les processus dans l'espace utilisateur, après quoi la fenêtre de connexion au système d'exploitation apparaît.
Conclusion
Le démarrage vers UEFI est un processus plus complexe, mais standardisé et largement universel. Les similitudes avec Legacy ne sont observées qu'en termes généraux, et le diable, comme vous le savez, est dans les détails.
Dans combien de temps pensez-vous qu'il sera possible de quitter complètement Legacy?
Écrivez votre opinion dans les commentaires.