Article de reference

UEFI

Menu de sélection de l'ordre de démarrage sur un Lenovo ThinkPad T470 compatible UEFI et BIOS L'implémentation UEFI est généralement stockée sur une mémoire flash de type NOR si...

Worldlex WikiFrancaisLecture gratuite

L'interface UEFI ( Firmware Interface une spécification de l' architecture micrologiciel d'une plateforme informatique . Lors de la mise sous tension d' ordinateur , l'implémentation UEFI s'exécute généralement en premier, avant le système d'exploitation ou tout autre programme. Parmi les exemples, citons AMI Aptio , Phoenix SecureCore , TianoCore EDK II et InsydeH2O .

L'UEFI remplace le BIOS présent dans la ROM de démarrage de tous les ordinateurs personnels compatibles IBM PC [ tout en assurant une rétrocompatibilité avec le BIOS grâce au démarrage CSM . Contrairement au BIOS, initialement développé par IBM comme une architecture propriétaire, la spécification UEFI est gérée par un consortium industriel. La plupart des implémentations de firmware de production pour les deux restent propriétaires.

Intel a développé la spécification originale de l'interface EFI ( Extensible Firmware Interface ). La dernière version Intel d'EFI était la 1.10, sortie en 2005. Les versions suivantes ont été développées sous l'appellation UEFI par le forum UEFI .

L'UEFI est indépendant de la plateforme et du langage de programmation, mais le C est utilisé pour l'implémentation de référence TianoCore EDKII.

Histoire

L'idée d'EFI est née lors du développement initial des premiers systèmes Intel-HP Itanium au milieu des années 1990. Les limitations du BIOS étaient devenues trop contraignantes pour les grandes plateformes de serveurs auxquelles Itanium était destiné. Les efforts pour remédier à ces problèmes ont débuté en 1998 sous le nom d' Intel Boot Initiative . Ce projet a ensuite été renommé Extensible Firmware Interface (EFI).

La première implémentation UEFI open-source , Tiano, a été publiée par Intel en 2004. Tiano a depuis été remplacé par EDK et EDK II et est maintenant maintenu par la communauté TianoCore.

En juillet 2005, Intel a cessé le développement de la spécification EFI à la version 1.10 et l'a cédée à l' Unified EFI Forum , qui l'a développée sous le nom d' Unified Extensible Firmware Interface (UEFI). La spécification EFI originale reste la propriété d'Intel, qui fournit exclusivement des licences pour les produits basés sur EFI, tandis que la spécification UEFI appartient à l'UEFI Forum.

La version 2.0 de la spécification UEFI a été publiée le 31 janvier 2006. Elle a ajouté la cryptographie et la sécurité .

La version 2.1 de la spécification UEFI a été publiée le 7 janvier 2007. Elle a ajouté l'authentification réseau et l' architecture d'interface utilisateur (« Infrastructure d'interface humaine » dans UEFI).

La version 2.3.1 de la spécification UEFI a été publiée le 6 avril 2011. Elle a ajouté le démarrage sécurisé ainsi que la prise en charge de l'architecture ARM .

En octobre 2018, Arm a lancé Arm ServerReady, un programme de certification de conformité visant à garantir le bon fonctionnement des systèmes d'exploitation et des hyperviseurs standard sur les serveurs Arm. Ce programme exige que le firmware système soit conforme aux exigences de démarrage de base du serveur (SBBR). Les SBBR requièrent la conformité aux protocoles UEFI, ACPI et SMBIOS . En octobre 2020, Arm a annoncé l'extension du programme au marché de l' edge computing et de l'IoT . Le nouveau nom du programme est Arm SystemReady . Arm SystemReady a défini la spécification des exigences de démarrage de base ( BBR ), qui propose actuellement trois configurations, dont deux sont liées à l'UEFI : 1) SBBR : qui exige la conformité aux protocoles UEFI, ACPI et SMBIOS et convient aux environnements d'exploitation d'entreprise tels que Windows, Red Hat Enterprise Linux et VMware ESXi ; et 2) EBBR : qui exige la conformité à un ensemble d'interfaces UEFI, comme défini dans les exigences de démarrage de base embarquées ( EBBR ), et convient aux environnements embarqués tels que Yocto. De nombreuses distributions Linux et BSD prennent en charge les deux configurations.

En décembre 2018, Microsoft a annoncé le projet Mu, une version dérivée de TianoCore EDK II utilisée dans les produits Microsoft Surface et Hyper-V . Ce projet intègre un modèle de distribution de microprogramme basé sur les services.

La dernière spécification UEFI, version 2.11, a été publiée en décembre 2024.

Compatibilité

Compatibilité du processeur

L'UEFI prend en charge les architectures de processeur 32 bits ou supérieures. Toutefois, seuls les processeurs en mode little-endian sont pris en charge. La spécification UEFI, version 2.11, contient une documentation officielle pour les architectures de processeur suivantes :

x86 ( IA-32 , x86-64 )
Itanium ( IA-64 )
ARM ( AArch32 , AArch64 )
RISC-V (32 bits, 64 bits, 128 bits)
LoongArch (32 bits, 64 bits)

La prise en charge non officielle d'UEFI est en cours de développement pour POWERPC64 grâce à l'implémentation de TianoCore EDK II sur OPAL , la couche d'abstraction OpenPOWER, fonctionnant en mode little-endian . Pour MIPS , il existe également un projet non officiel, basé sur l'EDK original . Cependant, ces deux projets ont été abandonnés respectivement en novembre 2016 et septembre 2015.

L'UEFI n'autorise l'exécution que d'applications UEFI compatibles avec la largeur de bits du firmware, même si le processeur prend en charge des largeurs de bits inférieures ou supérieures. Par exemple, un firmware UEFI 64 bits ne peut exécuter que des applications UEFI 64 bits, même si le processeur fonctionne en mode 32 bits. Certains ordinateurs d'entrée de gamme ont été livrés avec un firmware UEFI 32 bits exécuté sur des processeurs 64 bits. Une fois qu'une application UEFI a terminé les services de démarrage et obtenu le contrôle total du système, il devient possible de modifier le mode d'exécution du processeur. Cependant, l'appel des services d'exécution nécessite un bref retour au mode processeur d'origine, car les services d'exécution ne peuvent être appelés que depuis le même mode processeur que celui utilisé par le firmware.

Depuis la version 3.15, le noyau Linux prend en charge le démarrage de noyaux 64 bits sur des implémentations de firmware UEFI 32 bits avec des processeurs x86-64, ce qui exige que le chargeur de démarrage UEFI prenne en charge le protocole de transfert EFI. Ce protocole permet aux chargeurs de démarrage UEFI de déléguer l'initialisation UEFI au stub de démarrage EFI du noyau, de sorte que seul ce dernier effectue l'initialisation UEFI.

Compatibilité des périphériques de disque

par disque) sont assouplies. Plus précisément, le GPT autorise une taille maximale de disque et de partition de 8 Zio avec des secteurs de 512 octets. La spécification UEFI prend uniquement en charge les partitions FAT12 / 16 / 32 , sur les disques GPT ou MBR ainsi que sur les disques optiques formatés El Torito . Bien que GPT fasse partie de la norme UEFI, il peut également être utilisé par les PC BIOS pour démarrer un système d'exploitation.

Linux

dans le schéma GPT et est utilisée par GRUB uniquement dans les configurations BIOS-GPT. Du point de vue de GRUB, ce type de partition n'existe pas en cas de partitionnement MBR. Cette partition est inutile si le système est basé sur UEFI, car l'intégration du code de seconde étape n'est alors pas nécessaire.

Les systèmes UEFI peuvent accéder aux disques GPT et démarrer directement à partir de ceux-ci, ce qui permet à Linux d'utiliser les méthodes de démarrage UEFI. Le démarrage de Linux à partir de disques GPT sur les systèmes UEFI implique la création d'une partition système EFI (ESP), qui contient les applications UEFI telles que les chargeurs de démarrage, les noyaux du système d'exploitation et les logiciels utilitaires. Cette configuration est généralement appelée UEFI-GPT , et il est recommandé que l'ESP ait une taille minimale de 512 Mo et soit formatée avec le système de fichiers FAT32 pour une compatibilité maximale.

Pour assurer la rétrocompatibilité , certaines implémentations UEFI prennent également en charge le démarrage à partir de disques partitionnés MBR via le module de support de compatibilité (CSM), qui garantit la compatibilité avec les anciens BIOS. Dans ce cas, le démarrage de Linux sur les systèmes UEFI est identique à celui sur les systèmes BIOS traditionnels.

Microsoft Windows

Windows 11 , les versions 64 bits de Windows Vista SP1/SP2 et 7 , ainsi que les versions 32 bits et 64 bits de Windows 8 , 8.1 et 10 peuvent démarrer à partir d'un disque GPT d'une capacité supérieure à 2 To .

Caractéristiques

Services

EFI définit deux types de services : les services de démarrage et les services d’exécution . Les services de démarrage sont disponibles uniquement lorsque le firmware contrôle la plateforme (c’est-à-dire avant l’ ExitBootServices()appel système) et comprennent les consoles texte et graphique sur divers périphériques, ainsi que les services de bus, de blocs et de fichiers. Les services d’exécution restent accessibles pendant le fonctionnement du système d’exploitation ; ils incluent des services tels que la date, l’heure et l’accès à la NVRAM .

Services du protocole de sortie graphique (GOP): Le protocole de sortie graphique (GOP) fournit des services d'exécution ; voir également la section « Fonctionnalités graphiques » ci-dessous. Le système d'exploitation est autorisé à écrire directement dans le tampon d'image et le flux de bits fournis par le GOP en mode d'exécution.
Services de mappage de mémoire UEFI
Services SMM
Services ACPI
Services SMBIOS
Services Devicetree (pour processeurs RISC)
Services variables: Les variables UEFI permettent de stocker des données, notamment des données non volatiles. Certaines variables UEFI sont partagées entre le microprogramme de la plateforme et le système d'exploitation. Les espaces de noms de variables sont identifiés par des GUID, et les variables sont des paires clé/valeur. Par exemple, les variables UEFI peuvent être utilisées pour conserver les messages d'erreur dans la NVRAM après un plantage, afin que le système d'exploitation puisse les récupérer après un redémarrage.
Services horaires: L'UEFI fournit des services de synchronisation temporelle. Ces services incluent la prise en charge des fuseaux horaires et de l'heure d'été, permettant ainsi de régler l' horloge matérielle temps réel sur l'heure locale ou UTC. Sur les machines utilisant une horloge temps réel PC-AT, l'horloge matérielle doit par défaut être réglée sur l'heure locale pour assurer la compatibilité avec Windows basé sur le BIOS, sauf si vous utilisez des versions récentes et qu'une entrée du registre Windows est configurée pour indiquer l'utilisation de l'UTC.

Applications

Interaction entre le gestionnaire de démarrage EFI et les pilotes EFI

L'UEFI exécute des programmes indépendants, appelés applications UEFI, stockés sous forme de fichiers sur la partition système EFI. Ces applications peuvent être lancées via l'interface UEFI Shell, le gestionnaire de démarrage du firmware ou d'autres applications UEFI, et peuvent être développées indépendamment du fabricant d'origine (OEM).

Un chargeur d'amorçage de système d'exploitation, tel que GRUB , rEFInd , systemd-boot ou le Gestionnaire de démarrage Windows , est un type d'application UEFI. Il charge certains fichiers du système d'exploitation en mémoire et les exécute. De plus, un chargeur d'amorçage peut fournir une interface utilisateur permettant de sélectionner une autre application UEFI à exécuter. Les utilitaires comme UEFI Shell sont également des applications UEFI.

Protocoles

EFI définit les protocoles comme un ensemble d'interfaces logicielles utilisées pour la communication entre deux modules binaires. Tous les pilotes EFI doivent fournir des services à d'autres via ces protocoles. Les protocoles EFI sont similaires aux appels d'interruption du BIOS .

Pilotes de périphériques

Outre les pilotes de périphériques spécifiques à l'architecture de jeu d'instructions standard ( ISA), EFI fournit un pilote de périphérique indépendant de l'ISA , stocké en mémoire non volatile sous forme de bytecode EFI ( EBC) . Le microprogramme système dispose d'un interpréteur pour les images EBC. En ce sens, EBC est analogue à Open Firmware , le microprogramme indépendant de l'ISA utilisé notamment dans les ordinateurs Apple Macintosh et Sun Microsystems SPARC basés sur PowerPC .

Certains pilotes EFI spécifiques à une architecture (hors code octet EFI) pour certains types de périphériques peuvent disposer d'interfaces utilisables par le système d'exploitation. Cela permet à ce dernier de s'appuyer sur EFI pour que les pilotes assurent les fonctions graphiques et réseau de base avant, et si, les pilotes spécifiques au système d'exploitation sont chargés.

Dans d'autres cas, le pilote EFI peut être un pilote de système de fichiers permettant le démarrage à partir d'autres types de volumes de disque. On peut citer comme exemples les pilotes efifs pour 37 systèmes de fichiers (basés sur le code GRUB2 ), utilisés par Rufus pour le chargement en chaîne de partitions ESP NTFS.

Fonctionnalités graphiques

La spécification EFI 1.0 définissait un protocole UGA (Universal Graphic Adapter) comme moyen de prendre en charge les fonctionnalités graphiques. UEFI n'incluait pas l'UGA et l'a remplacé par le GOP (Graphics Output Protocol) .

L'UEFI 2.1 a défini une « Infrastructure d'Interface Humaine » (IIU) pour gérer les entrées utilisateur, les chaînes de caractères localisées, les polices et les formulaires (au sens HTML ). Ces éléments permettent aux fabricants d'équipement d'origine (OEM) ou aux fournisseurs de BIOS indépendants (IBV) de concevoir des interfaces graphiques pour la configuration avant démarrage. L'UEFI utilise par défaut l'UTF-16 pour encoder les chaînes de caractères ; depuis au moins la version 2.4, il autorise l'utilisation de l'ASCII pour encoder uniquement les chaînes de caractères ASCII.

La plupart des premières implémentations de firmware UEFI étaient basées sur la console. Aujourd'hui, de nombreuses implémentations de firmware UEFI sont basées sur une interface graphique.

partition système EFI

Contrairement au BIOS traditionnel des PC, l'UEFI ne repose pas sur les secteurs de démarrage du disque dur. Il définit plutôt un gestionnaire de démarrage dans sa spécification. À la mise sous tension, ce gestionnaire vérifie la configuration de démarrage et, en fonction de ses paramètres, exécute le chargeur de démarrage ou le noyau du système d'exploitation spécifié . La configuration de démarrage est définie par des variables stockées dans la mémoire NVRAM persistante de l'ordinateur , notamment celles indiquant les chemins d'accès aux chargeurs de démarrage ou aux noyaux du système d'exploitation.

L'UEFI peut détecter automatiquement le chargeur d'amorçage du système d'exploitation, ce qui facilite le démarrage à partir de périphériques amovibles tels que les clés USB . Cette détection automatique repose sur des chemins d'accès standardisés au chargeur d'amorçage, lesquels varient selon l' architecture de l'ordinateur . Le format du chemin d'accès est défini comme suit : <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; par exemple, sur un système x86-64 , le chemin d'accès au chargeur d'amorçage est \efi\boot\bootx64.efi [ , et sur une architecture ARM64, il est efi\boot\bootaa64.efi .\\EFI\\BOOT\\BOOT.EFI"}},"i":0}}]

Le démarrage des systèmes UEFI à partir de disques partitionnés GPT est communément appelé démarrage UEFI-GPT , bien que la spécification UEFI exige une prise en charge complète des tables de partition MBR. Certaines implémentations de firmware UEFI basculent immédiatement vers un démarrage CSM basé sur le BIOS en fonction du type de la table de partition du disque de démarrage, empêchant ainsi le démarrage UEFI à partir d'une partition système EFI sur des disques partitionnés MBR ; ce schéma de démarrage est communément appelé UEFI-MBR .

Il est également courant qu'un gestionnaire de démarrage dispose d'une interface utilisateur textuelle permettant à l'utilisateur de sélectionner le système d'exploitation (ou l'utilitaire de configuration) souhaité parmi une liste d'options de démarrage disponibles.

Sur les plateformes PC, le firmware prenant en charge le démarrage UEFI est souvent appelé « BIOS UEFI », bien que certaines plateformes x86 plus récentes excluent totalement la prise en charge du CSM.

Démarrage du CSM

Pour garantir la rétrocompatibilité, les implémentations du firmware UEFI sur les PC peuvent prendre en charge le démarrage en mode BIOS hérité à partir de disques partitionnés MBR grâce au module de support de compatibilité (CSM). Dans ce cas, le démarrage s'effectue de la même manière que sur les systèmes BIOS hérités, en ignorant la table de partitions et en se basant sur le contenu d'un secteur de démarrage .

Le module de compatibilité permet l'utilisation de systèmes d'exploitation et de ROM optionnelles anciens qui ne prennent pas en charge l'UEFI. Il fournit également les fonctionnalités requises du mode de gestion système (SMM) ancien (CompatibilitySmm), en plus de celles fournies par le SMM UEFI. À titre d'exemple, il assure la prise en charge des périphériques USB anciens pour le clavier et la souris, en émulant leurs équivalents PS/2 classiques .

En novembre 2017, Intel a annoncé son intention de supprimer progressivement la prise en charge de CSM pour les plateformes clientes d'ici 2020.

En juillet 2022, Kaspersky Labs a publié des informations concernant un Rootkit conçu pour démarrer en chaîne du code malveillant sur des machines utilisant le chipset Intel H81 et le module de support de compatibilité des cartes mères concernées.

En août 2023, Intel a annoncé son intention de supprimer progressivement la prise en charge du CSM pour les plateformes serveur d'ici 2024.

Démarrage réseau

La spécification UEFI inclut la prise en charge du démarrage réseau via l' environnement d'exécution de prédémarrage (PXE). Les protocoles réseau de démarrage PXE comprennent le protocole Internet ( IPv4 et IPv6 ), le protocole de datagramme utilisateur (UDP), le protocole de configuration dynamique des hôtes (DHCP), le protocole de transfert de fichiers simplifié (TFTP) et iSCSI .

Les images du système d'exploitation peuvent être stockées à distance sur des réseaux de stockage (SAN), avec l'interface iSCSI ( Internet Small Computer System Interface ) et le protocole FCoE ( Fibre Channel over Ethernet ) pris en charge pour l'accès aux SAN.

La version 2.5 de la spécification UEFI ajoute la prise en charge de l'accès aux images de démarrage via HTTP .

Démarrage sécurisé

2025La prise en charge de FreeBSD est en phase de planification.

Interface UEFI

L'UEFI fournit un environnement shell permettant d'exécuter d'autres applications UEFI, notamment les chargeurs de démarrage UEFI . De plus, les commandes disponibles dans le shell UEFI permettent d'obtenir diverses informations sur le système ou le firmware, comme la carte mémoire , la modification des variables du gestionnaire de démarrage , l'exécution de programmes de partitionnement , le chargement des pilotes UEFI et l'édition de fichiers texte . memmapbcfgdiskpartedit

Le code source d'un shell UEFI peut être téléchargé depuis le projet TianoCore UDK/EDK2 d' Intel . Un ShellBinPkg précompilé est également disponible. Le Shell v2 fonctionne de manière optimale sur les systèmes UEFI 2.3 et versions ultérieures et est recommandé de préférence au Shell v1 sur ces systèmes. Le Shell v1 devrait fonctionner sur tous les systèmes UEFI.

Les méthodes de lancement de l'interface UEFI dépendent du fabricant et du modèle de la carte mère . Certaines cartes mères proposent une option directe de lancement dans la configuration du firmware ; par exemple, la version compilée x86-64 de l'interface doit être disponible <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. D'autres systèmes intègrent déjà une interface UEFI, accessible par des combinaisons de touches appropriées. Pour d'autres systèmes encore, la solution consiste soit à créer une clé USB dédiée, soit à ajouter manuellement bcfgune option de démarrage associée à la version compilée de l'interface.

Commandes

Voici une liste des commandes prises en charge par l'interpréteur de commandes EFI.

SEC – Phase de sécurité

Il s'agit de la première étape du démarrage UEFI, précédée par du code binaire spécifique à la plateforme (par exemple, Intel ME , AMD PSP , microcode du processeur ). Ce code minimal, écrit en langage assembleur pour l'architecture concernée, initialise une mémoire temporaire (souvent le cache du processeur faisant office de RAM (CAR) ou le processeur de démarrage intégré du SoC ) et sert de racine de confiance logicielle du système, avec la possibilité de vérifier l'interface d'exécution (PEI) avant le transfert.

Responsabilités

Initialisation de la mémoire temporaire pour l'étape suivante, PEI.
Racine de confiance, par la vérification de l'intégrité de l'Île-du-Prince-Édouard.
Transmission des informations de transfert à la fondation PEI. Ces informations comprennent l'emplacement et la taille de la mémoire temporaire, l'emplacement et la taille de la pile et l'état de la plateforme.

PEI – Initialisation pré-EFI

La seconde étape du démarrage UEFI consiste en un répartiteur prenant en compte les dépendances, qui charge et exécute les modules PEI (PEIM) pour gérer les tâches d'initialisation matérielle initiales, telles que l'initialisation de la mémoire principale (initialisation du contrôleur mémoire et de la DRAM ) et les opérations de récupération du firmware. Elle est également responsable de la détection du mode de démarrage actuel et de la gestion de nombreuses opérations ACPI S3. En cas de reprise ACPI S3, elle restaure de nombreux registres matériels à leur état antérieur à la mise en veille. PEI utilise également CAR. L'initialisation à cette étape implique la création de structures de données en mémoire et l'établissement de valeurs par défaut au sein de ces structures.

Cette étape comprend plusieurs composantes, notamment la fondation PEI, les PEIM et le PPI. Compte tenu des ressources limitées disponibles, cette étape doit être minimale et se concentrer sur la préparation de l'étape suivante, DXE, qui sera plus complète.

Fondation de l'Île-du-Prince-Édouard

Après le transfert de la responsabilité de la plateforme à la SEC, la Fondation PEI prend en charge ses responsabilités. Celles-ci sont les suivantes :

Envoi réussi des PEIM (modules d'initialisation pré-EFI).
Initialisation de la mémoire permanente (RAM).
Passage à l'étape suivante : DXE.
Faciliter la communication des PEIM appelée PPI.

Répartiteur de l'Île-du-Prince-Édouard

Ce composant est responsable de l'appel des PEIM et de la gestion de leurs dépendances.

Modules d'initialisation pré-EFI

Il s'agit de pilotes PEI minimaux chargés de l'initialisation des composants matériels, tels que la mémoire permanente, le processeur, le chipset et la carte mère. Chaque pilote PEI a une fonction unique et se concentre sur une seule initialisation. Ces pilotes proviennent de différents fournisseurs.

Interfaces PEIMs-à-PEIMs

Il s'agit d'une structure de données composée de paires de pointeurs GUID. Les PPI sont découvertes par les PEIM via les services PEI.

Après une initialisation minimale du système pour DXE, la fondation PEI se localise et lui transfère le contrôle. La fondation PEI lance ensuite la fondation DXE via une interface de programmation spécifique appelée IPL (Initial Program Load).

DXE – Environnement d'exécution des pilotes

Cette étape comprend des modules C et un répartiteur prenant en compte les dépendances. La mémoire principale étant désormais disponible, le processeur, le chipset, la carte mère et les autres périphériques d'E/S sont initialisés dans DXE et BDS. L'initialisation à cette étape consiste à attribuer les chemins d'accès EFI aux périphériques connectés à la carte mère et à transférer les données de configuration à ces périphériques.

BDS – Sélection du périphérique de démarrage (Gestionnaire de démarrage)

BDS fait partie du DXE. À cette étape, les périphériques de démarrage sont initialisés, les pilotes UEFI ou les ROM d'option des périphériques PCI sont exécutés selon des variables architecturales définies appelées NVRAM , et les chargeurs de démarrage du système d'exploitation (tels que le Gestionnaire de démarrage Windows ) sont lancés.

TSL – Charge transitoire du système

Cette étape se situe entre la sélection du périphérique de démarrage et le passage au système d'exploitation. À ce stade, il est possible d'accéder à une interface UEFI ou d'exécuter une application UEFI, comme le chargeur de démarrage du système d'exploitation.

RT – Durée d'exécution

L'UEFI cède la main au système d'exploitation après l'exécution de ExitBootServices() . Un système d'exploitation compatible UEFI est alors responsable de la fermeture des services de démarrage, ce qui déclenche le déchargement par le firmware de tout le code et les données devenus inutiles, ne conservant que le code et les données des services d'exécution, tels que SMM et ACPI . Un système d'exploitation moderne classique privilégiera l'utilisation de ses propres programmes (comme les pilotes de noyau ) pour contrôler les périphériques matériels.

Lorsqu'un système d'exploitation ancien est utilisé, le CSM gérera cet appel en veillant à ce que le système soit compatible avec les exigences du BIOS ancien.

Usage

Mises en œuvre

L'implémentation EFI d'Intel est l' Intel Platform Innovation Framework , nom de code Tiano . Tiano fonctionne sur les processeurs Intel XScale , Itanium , IA-32 et x86-64 et est un logiciel propriétaire, bien qu'une partie du code ait été publiée sous licence BSD ou Eclipse Public License (EPL) sous le nom de TianoCore EDK II . TianoCore peut être utilisé comme charge utile pour coreboot .

L'implémentation UEFI de Phoenix Technologies est commercialisée sous la marque SecureCore Technology (SCT). American Megatrends propose sa propre implémentation de firmware UEFI connue sous le nom d'Aptio, tandis qu'Insyde Software propose InsydeH2O, et Byosoft propose ByoCore.

En décembre 2018, Microsoft a publié une version open source de son implémentation UEFI basée sur TianoCore EDK2 de la gamme Surface , Project Mu .

Une implémentation de l'API UEFI a été introduite dans le chargeur de démarrage universel ( U-Boot ) en 2017. Sur l' architecture ARMv8, les distributions Linux utilisent l'implémentation UEFI d'U-Boot conjointement avec GNU GRUB pour le démarrage (par exemple, SUSE Linux ), et il en va de même pour OpenBSD. Pour le démarrage à partir d'iSCSI , iPXE peut être utilisé comme application UEFI chargée par U-Boot.

Plateformes

Les premières stations de travail et serveurs Itanium d' Intel , sortis en 2000, implémentaient EFI 1.02.

Les premiers systèmes Itanium 2 de Hewlett-Packard , sortis en 2002, implémentaient EFI 1.10. Ces systèmes pouvaient démarrer Windows , Linux , FreeBSD et HP-UX . OpenVMS a ajouté la compatibilité UEFI en juin 2003.

En janvier 2006, Apple Inc. a commercialisé ses premiers ordinateurs Macintosh à processeur Intel . Ces systèmes utilisaient l'EFI au lieu de l'Open Firmware , utilisé sur ses précédents systèmes PowerPC. Le 5 avril 2006, Apple a lancé Boot Camp , qui génère un disque de pilotes Windows et un outil de partitionnement non destructif permettant l'installation de Windows XP ou Vista sans réinstallation de Mac OS X (désormais macOS). Une mise à jour du firmware a également été publiée, ajoutant la compatibilité BIOS à son implémentation EFI. Les modèles Macintosh suivants ont été livrés avec ce nouveau firmware.

En 2005, plus d'un million de systèmes Intel ont été livrés avec l'implémentation UEFI d'Intel. De nouveaux produits mobiles, de bureau et serveurs, utilisant l'implémentation UEFI d'Intel, ont commencé à être livrés en 2006. Par exemple, les cartes mères utilisant la série de chipsets Intel 945 utilisent l'implémentation du firmware UEFI d'Intel.

Depuis 2005, EFI a également été implémenté sur des architectures non-PC, telles que les systèmes embarqués basés sur des cœurs XScale .

Le kit de développement EFI (EDK) inclut une cible NT32, permettant l'exécution de microprogrammes et d'applications EFI au sein d'une application Windows . Cependant, l'EDK NT32 n'autorise aucun accès direct au matériel. Par conséquent, seule une partie des applications et pilotes EFI peut être exécutée par la cible EDK NT32.

En 2008, de plus en plus de systèmes x86-64 ont adopté l'UEFI. Si nombre d'entre eux n'autorisent encore que le démarrage des systèmes d'exploitation BIOS via le module de compatibilité (CSM) (et ne sont donc pas perçus comme UEFI par l'utilisateur), d'autres ont commencé à permettre le démarrage des systèmes d'exploitation UEFI. C'est le cas, par exemple, du serveur IBM x3450, des cartes mères MSI avec ClickBIOS et des ordinateurs portables HP EliteBook.

En 2009, IBM a commercialisé des machines System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) et BladeCenter HS22 compatibles UEFI. Dell a commercialisé des serveurs PowerEdge T610, R610, R710, M610 et M710 compatibles UEFI. D'autres systèmes disponibles sur le marché sont mentionnés dans un livre blanc sur l'UEFI.

En 2011, les principaux fournisseurs (tels que ASRock , Asus , Gigabyte et MSI ) ont lancé plusieurs cartes mères destinées au grand public utilisant le chipset Intel série 6 LGA 1155 et les chipsets AMD série 9 AM3+ avec UEFI.

Avec la sortie de Windows 8 en octobre 2012, les exigences de certification de Microsoft imposent désormais aux ordinateurs d'intégrer un microprogramme conforme à la spécification UEFI. De plus, si l'ordinateur prend en charge la fonctionnalité « Veille connectée » de Windows 8 (qui permet une gestion de l'alimentation comparable à celle des smartphones , avec une sortie de veille quasi instantanée), le microprogramme ne doit pas contenir de module de prise en charge de la compatibilité (CSM). Par conséquent, les systèmes compatibles avec la veille connectée sont incapables de démarrer les systèmes d'exploitation utilisant le BIOS hérité.

En octobre 2017, Intel a annoncé qu'il supprimerait la prise en charge du BIOS PC hérité de tous ses produits d'ici 2020, au profit de l'UEFI Classe 3. En 2019, tous les ordinateurs basés sur des plateformes Intel ne disposent plus de la prise en charge du BIOS PC hérité.

Systèmes d'exploitation

Un système d'exploitation pouvant démarrer depuis (U)EFI est appelé système d'exploitation compatible (U)EFI, conformément à la spécification (U)EFI. Ici, l'expression « démarré depuis (U)EFI » signifie démarrer directement le système à l'aide d'un chargeur de système d'exploitation (U)EFI stocké sur n'importe quel périphérique de stockage. L'emplacement par défaut du chargeur de système d'exploitation est `/usr/local/bin` <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI, où le nom abrégé du type de machine peut être IA32` /usr / local/bin`, X64`/ usr/local/bin`, `/usr/local/bin` ou `/usr/local/bin` . . Certains fournisseurs de systèmes d'exploitation peuvent utiliser leurs propres chargeurs de démarrage et modifier l'emplacement de démarrage par défaut.IA64ARMAA64

Le noyau Linux est capable d'utiliser l'EFI au démarrage depuis le début des années 2000 , grâce au chargeur de démarrage EFI elilo et, plus récemment, aux versions EFI de GRUB ou de systemd-boot . Grub+Linux prend également en charge le démarrage à partir d'une table de partition GUID sans UEFI . La distribution Ubuntu a ajouté la prise en charge du démarrage sécurisé UEFI à partir de la version 12.10 . Le noyau Linux peut être compilé avec l'option de s'exécuter comme chargeur de démarrage EFI autonome grâce à la fonctionnalité de stub de démarrage EFI. Dans le noyau Linux, le protocole ACPI (généralement utilisé sur les machines compatibles PC) ou le protocole DeviceTree (généralement utilisé sur les smartphones et les tablettes) peuvent être utilisés avec l'UEFI
HP-UX utilise (U)EFI comme mécanisme de démarrage sur les systèmes IA-64 depuis 2002.
OpenVMS utilise EFI sur IA-64 depuis sa première version d'évaluation en décembre 2003, et pour les versions de production depuis janvier 2005. OpenVMS sur x86-64 utilise également UEFI pour démarrer le système d'exploitation.
Apple utilise EFI pour sa gamme de Mac à processeur Intel . Mac OS X v10.4 Tiger et Mac OS X v10.5 Leopard implémentent EFI v1.10 en mode 32 bits même sur les processeurs 64 bits, mais la prise en charge complète est arrivée avec OS X v10.8 Mountain Lion .
Les versions Itanium de Windows 2000 (Advanced Server Limited Edition et Datacenter Server Limited Edition ; basées sur le code source préliminaire de Windows Server 2003 ) ont implémenté EFI 1.10 en 2002. Windows XP Édition 64 bits , Windows 2000 Advanced Server Limited Edition (préversion de Windows Server 2003) et Windows Server 2003 pour IA-64 , tous destinés à la famille de processeurs Intel Itanium , implémentent EFI, une exigence de la plateforme via la spécification DIG64 .
Microsoft a introduit l'UEFI pour les systèmes d'exploitation Windows 64 bits avec Windows Vista SP1 et Windows Server 2008. Cependant, seules les cartes graphiques universelles (UGA) 1.1 et les BIOS hérités INT 10h sont prises en charge ; le protocole de sortie graphique (GOP) n'est pas pris en charge. Par conséquent, les PC exécutant les versions 64 bits de Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008 et Windows Server 2008 R2 sont compatibles avec l'UEFI de classe 2. L'UEFI 32 bits n'était initialement pas pris en charge, car les fabricants n'avaient aucun intérêt à produire un firmware UEFI 32 bits natif, compte tenu de la prédominance de l'informatique 64 bits . Windows 8 a finalement introduit des optimisations supplémentaires pour les systèmes UEFI, notamment la prise en charge du protocole de sortie graphique (GOP), un démarrage plus rapide, la prise en charge de l'UEFI 32 bits et la prise en charge du démarrage sécurisé. Depuis Windows 8 , le firmware UEFI avec protocole ACPI est obligatoire pour les systèmes d'exploitation Microsoft Windows basés sur ARM. Microsoft a rendu l'UEFI obligatoire pour exécuter Windows avec Windows 11 , les éditions IoT Enterprise de Windows 11 étant exemptées de cette exigence depuis la version 24H2.
Le 5 mars 2013, la Fondation FreeBSD a octroyé une subvention à un développeur souhaitant ajouter la prise en charge d'UEFI au noyau et au chargeur de démarrage de FreeBSD . Les modifications ont d'abord été stockées dans une branche distincte du code source de FreeBSD, puis intégrées au code source principal le 4 avril 2014 (révision 264095) ; elles incluent également la prise en charge dans l'installateur. La prise en charge du démarrage UEFI pour amd64 est apparue pour la première fois dans FreeBSD 10.1 et pour arm64 dans FreeBSD 11.0.
NetBSD prend en charge UEFI depuis la version 8.0 pour les architectures i386 et amd64 ainsi que sur diverses plateformes ARM depuis la version 9.0.
Oracle Solaris 11.1 et versions ultérieures prennent en charge le démarrage UEFI pour les systèmes x86 dotés d'un firmware UEFI version 2.1 ou ultérieure. GRUB 2 est utilisé comme chargeur de démarrage sur x86.
OpenBSD 5.9 a introduit la prise en charge du démarrage UEFI pour les systèmes x86 64 bits en utilisant son propre chargeur personnalisé, OpenBSD 6.0 a étendu cette prise en charge pour inclure ARMv7.
illumos a ajouté la prise en charge UEFI de base en octobre 2017.
ArcaOS prend en charge le démarrage UEFI depuis la version 5.1. La prise en charge UEFI d'ArcaOS émule des fonctionnalités spécifiques du BIOS dont dépend le système d'exploitation (notamment les interruptions INT 10H et INT 13H ).

Avec la virtualisation

HP Integrity Virtual Machines assure le démarrage UEFI sur les serveurs HP Integrity. Il fournit également un environnement UEFI virtualisé pour les systèmes d'exploitation invités compatibles UEFI.
Intel héberge un projet de firmware de machine virtuelle ouverte sur SourceForge.
Le logiciel VMware Fusion 3 pour Mac OS X peut démarrer des machines virtuelles Mac OS X Server en utilisant l'UEFI.
Les versions de VMware Workstation antérieures à la version 11 prennent en charge UEFI de manière non officielle, mais cette fonctionnalité doit être activée manuellement en modifiant le fichier .vmx. VMware Workstation version 11 et ultérieures prennent en charge UEFI, que le système hôte physique soit basé sur UEFI ou non. VMware Workstation 14 (et par conséquent Fusion 10) ajoute la prise en charge de la fonctionnalité de démarrage sécurisé d'UEFI.
L’ hyperviseur VMware ESXi 5.0 prend officiellement en charge UEFI. La version 6.5 ajoute la prise en charge du démarrage sécurisé.
VirtualBox prend en charge l'UEFI depuis la version 3.1, mais est limité aux systèmes d'exploitation Unix/Linux et à Windows 8 et versions ultérieures (ne fonctionne pas avec Windows Vista x64 et Windows 7 x64).
QEMU / KVM peut être utilisé avec le firmware Open Virtual Machine (OVMF) fourni par TianoCore .
La deuxième génération de la machine virtuelle Microsoft Hyper-V prend en charge l'UEFI virtualisé.
Les machines virtuelles protégées de Google Cloud Platform prennent en charge l'UEFI virtualisé pour activer le démarrage sécurisé.

vulnérabilités

Des failles d'implémentation de l'UEFI ont été exploitées pour assurer la persistance de l'accès malveillant à un système compromis, même après un redémarrage, une réinstallation du système d'exploitation, voire le remplacement partiel de composants physiques, comme un stockage flash persistant PCI corrompu. Des vulnérabilités existaient déjà en 2023, malgré l'activation du démarrage sécurisé. En 2023, Microsoft a publié un avertissement concernant le malware UEFI BlackLotus .

Développement d'applications

Le kit de développement d'applications EDK2 (EADK) permet d'utiliser les fonctions de la bibliothèque C standard dans les applications UEFI. L'EADK peut être téléchargé gratuitement depuis le projet SourceForge TianoCore UDK/EDK2 d' Intel . À titre d'exemple, un portage de l' interpréteur Python est disponible en tant qu'application UEFI grâce à l'EADK. Le développement s'effectue sur GitHub depuis la version .UDK2015.

Critique

De nombreux militants des droits numériques ont protesté contre l'UEFI. coreboot , et Cory Doctorow , militant des droits numériques, ont critiqué l'UEFI, la considérant comme une tentative de priver l'utilisateur d'un véritable contrôle sur son ordinateur. Des critiques, comme Ronald G. Minnich, co-auteur de coreboot, font valoir que l'UEFI perpétue l'organisation historique qui exige deux pilotes distincts – l'un pour le micrologiciel et l'autre pour le système d'exploitation – pour la plupart des matériels.

Le projet open source TianoCore fournit également des UEFI. TianoCore ne dispose pas des pilotes et modules de firmware spécialisés nécessaires à l'initialisation des fonctions du chipset, mais il constitue l'une des nombreuses options de charge utile de coreboot . Le développement de coreboot requiert la collaboration des fabricants de chipsets afin de fournir les spécifications nécessaires à la création des pilotes d'initialisation.

Démarrage sécurisé

8 devaient permettre le passage en mode personnalisé ou la désactivation du démarrage sécurisé, contrairement aux systèmes utilisant l' architecture ARM . Windows 10 permet aux OEM de décider si les utilisateurs de leurs systèmes x86 peuvent gérer ou non le démarrage sécurisé.

D'autres développeurs ont soulevé des inquiétudes quant aux aspects juridiques et pratiques de la mise en œuvre du démarrage sécurisé sur les systèmes Linux en général. Matthew Garrett, ancien développeur chez Red Hat, a fait remarquer que les conditions de la licence publique générale GNU version 3 pourraient empêcher l'utilisation du chargeur de démarrage unifié GNU GRand sans que le développeur de la distribution ne divulgue la clé privée (la Free Software Foundation a toutefois clarifié sa position depuis, assurant que la responsabilité de la mise à disposition des clés incombait au fabricant du matériel) , et qu'il serait également difficile pour les utilisateurs avancés de créer des noyaux personnalisés compatibles avec le démarrage sécurisé sans les auto-signer . D'autres développeurs ont suggéré de fournir des versions signées de Linux avec une autre clé, mais ont noté qu'il serait difficile de convaincre les fabricants d'ordinateurs de livrer leurs machines avec la clé requise en plus de la clé Microsoft

Plusieurs distributions Linux majeures ont développé différentes implémentations du démarrage sécurisé. Garrett lui-même a développé un chargeur de démarrage minimal appelé shim, un chargeur de démarrage précompilé et signé qui permet à l'utilisateur de faire confiance individuellement aux clés fournies par les distributions Linux. Ubuntu 12.10 utilise une version plus ancienne de shim préconfigurée pour être utilisée avec la clé de Canonical , qui vérifie uniquement le chargeur de démarrage et autorise le chargement de noyaux non signés. Les développeurs ont estimé que la pratique consistant à ne signer que le chargeur de démarrage est plus réaliste, car un noyau de confiance ne sécurise que l' espace utilisateur , et non l'état de pré-démarrage pour lequel le démarrage sécurisé est conçu. Cela permet également aux utilisateurs de compiler leurs propres noyaux et d'utiliser des modules de noyau personnalisés , sans avoir à reconfigurer le système. Canonical conserve également sa propre clé privée pour signer les installations d'Ubuntu préinstallées sur les ordinateurs OEM certifiés exécutant ce système d'exploitation. L'entreprise prévoit également d'imposer une exigence de démarrage sécurisé

La question de la signature du noyau du système d'exploitation et de ses modules fait débat ; si les spécifications UEFI ne l'exigent pas, Microsoft affirme que ses obligations contractuelles l'imposent et se réserve le droit de révoquer tout certificat utilisé pour signer du code susceptible de compromettre la sécurité du système. Sous Windows, si le démarrage sécurisé est activé, tous les pilotes du noyau doivent être signés numériquement ; le chargement des pilotes non WHQL peut être refusé. En février 2013, un autre développeur de Red Hat a tenté de soumettre un correctif au noyau Linux afin de lui permettre d'analyser la signature Authenticode de Microsoft à l'aide d'une clé X.509 principale intégrée aux fichiers PE signés par Microsoft. Cependant, cette proposition a été critiquée par Linus Torvalds, créateur de Linux, qui a fait valoir que Red Hat se prêtait ainsi au contrôle de Microsoft sur l'infrastructure de démarrage sécurisé.

Le 26 mars 2013, le groupe espagnol de développement de logiciels libres Hispalinux a déposé une plainte officielle auprès de la Commission européenne , arguant que les exigences de démarrage sécurisé de Microsoft sur les systèmes OEM étaient « obstructives » et anticoncurrentielles .

Lors de la conférence Black Hat en août 2013, un groupe de chercheurs en sécurité a présenté une série d'exploits dans des implémentations spécifiques de fournisseurs d'UEFI qui pourraient être utilisés pour exploiter le démarrage sécurisé.

En août 2016, il a été rapporté que deux chercheurs en sécurité avaient découvert la « clé d'or », la clé de sécurité utilisée par Microsoft pour signer ses systèmes d'exploitation. Techniquement, aucune clé n'a été exposée, mais un binaire exploitable signé avec cette clé l'a été. Cela permet à un logiciel de s'exécuter comme s'il était signé par Microsoft, ce qui présente des risques potentiels d' attaques par rootkit et bootkit . Cela complique également les efforts de correction, car un correctif peut potentiellement être désactivé en le remplaçant par le binaire exploitable signé. Microsoft a déclaré que la vulnérabilité n'affecte que l'architecture ARM et les appareils Windows RT et a publié deux mises à jour ; cependant, des rapports ont indiqué que ces mises à jour n'empêchent pas complètement l'exploitation, car la résolution complète de la vulnérabilité nécessiterait le remplacement de la clé dans le firmware de l'utilisateur final.

Le 1er mars 2023, des chercheurs d'ESET ont annoncé la découverte de « BlackLotus », décrit comme le premier bootkit UEFI actif capable de contourner le démarrage sécurisé UEFI en exploitant les limitations des mises à jour de sécurité précédentes.

En août 2024, les mises à jour de sécurité de Windows 11 et Windows 10 ont appliqué les paramètres de ciblage avancé du démarrage sécurisé (SBAT) à la NVRAM UEFI des appareils, ce qui a empêché le chargement de certaines distributions Linux. SBAT est un protocole pris en charge par les nouvelles versions du Gestionnaire de démarrage Windows et du shim, qui empêche le chargement de chargeurs de démarrage intermédiaires défectueux ou vulnérables (généralement des versions plus anciennes du Gestionnaire de démarrage Windows et de GRUB ) lors du processus de démarrage. Cette modification a été annulée le mois suivant.

En juin 2025, LWN.net a signalé que le certificat Microsoft UEFI CA 2011 expirerait le 27 juin 2026, ce qui pourrait empêcher le chargement de certaines distributions Linux si le démarrage sécurisé est activé. Cependant, dans TianoCore EDK II ainsi que dans de nombreuses implémentations UEFI commerciales (telles que AMI Aptio), la vérification de la date et de l'heure du certificat de démarrage sécurisé est généralement désactivée par défaut.

De nombreuses distributions Linux prennent en charge le démarrage sécurisé UEFI , tels que RHEL (RHEL 7 et versions ultérieures), CentOS (CentOS 7 et versions ultérieures ), Ubuntu , Fedora , Debian (Debian 10 et versions ultérieures ), OpenSUSE et SUSE Linux Enterprise .

Problèmes de firmware

Un certain nombre de problèmes techniques ont été signalés concernant des implémentations spécifiques du firmware UEFI dans des appareils commerciaux.

Suite à la sortie de Windows 8 en octobre 2012, il a été constaté que certains modèles d'ordinateurs Lenovo dotés du démarrage sécurisé présentaient un UEFI qui vérifiait la présence de « Windows Boot Manager » ou de « Red Hat Enterprise Linux » dans la description d'un système d'exploitation compatible UEFI, et refusait de le charger en l'absence de cette mention. Des difficultés de fonctionnement similaires ont été signalées concernant plusieurs modèles d'ordinateurs portables Toshiba , pour lesquels certains certificats de microprogramme requis pour le fonctionnement du démarrage sécurisé étaient manquants.

En janvier 2013, un problème de firmware concernant l'implémentation UEFI sur certains ordinateurs portables Samsung a été rendu public . Ce problème rendait les appareils totalement inutilisables après l'installation d'une distribution Linux en mode UEFI. Si les premiers rapports attribuaient le problème à des conflits avec un module du noyau conçu pour accéder aux fonctionnalités système des ordinateurs portables Samsung (incitant les responsables du noyau à désactiver le module sur les systèmes UEFI par mesure de sécurité), l'analyse de Matthew Garrett a indiqué que le problème était déclenché par le stockage d'un nombre excessif de variables UEFI dans la mémoire non volatile, un comportement qui pouvait également se produire dans certaines conditions sous Windows. Son analyse a conclu que le module du noyau associé provoquait l'écriture de vidages de messages du noyau dans l'espace de stockage du firmware, entraînant ainsi l'état de défaillance.