UEFI

Le standard UEFI (de l’anglais Unified Extensible Firmware Interface, signifiant en français : « Interface micrologicielle extensible unifiée ») définit une interface entre le micrologiciel (firmware) et le système d'exploitation (OS) d'un ordinateur. Cette interface succède sur certaines cartes-mères au BIOS.

Pour les articles homonymes, voir EFI.

Logo du standard.
Fonctionnement synthétique de l'EFI (Extensible Firmware Interface).

Histoire

L'UEFI fait suite à l'EFI (Extensible Firmware Interface), conçue par Intel pour les processeurs Itanium.[réf. nécessaire]

AMD, American Megatrends, Apple, ARM, Dell, HP, Intel, IBM, Insyde Software, Microsoft et Phoenix Technologies sont les promoteurs de l’UEFI Forum qui définissent les normes de cette technologie[1].

L’UEFI Forum travaille depuis 2005 sur les spécifications de l'UEFI et a publié les premières spécifications officielles de l'UEFI 2.0 au début de 2006. UEFI n'est donc pas une norme, mais un standard technique fruit du consensus d'un groupe d'industriels.

Description

L'UEFI offre de nombreux avantages sur le BIOS : fonctionnalités réseau en standard, interface graphique de bonne résolution, gestion intégrée d'installations multiples de systèmes d’exploitation et affranchissement de la limite des disques à 2,2 To.

Le BIOS, écrit en assembleur, limitait les modifications et/ou remplacements, gage de sûreté de fonctionnement et de sécurité.

L'UEFI est écrit en C, ce qui rend sa maintenance plus souple et reste acceptable en raison des coûts décroissants de la mémoire. Développé pour assurer l'indépendance entre système d'exploitation et plate-forme matérielle sur laquelle il fonctionne, l'UEFI est disponible sur les plates-formes Itanium (IA-64), x86 (32 et 64 bits) et ARM.

Généralités

Une des fonctions d'UEFI est l'amorçage d'un système d'exploitation, auparavant assurée par le BIOS.

Les spécifications de l'UEFI définissent un gestionnaire d'amorçage dont le rôle est de mettre en mémoire les pilotes et le chargeur du système d'exploitation nécessaire au démarrage. Ce chargeur est une classe d'application UEFI stockée sous forme de fichiers sur un système de fichiers accessible par micrologiciel. Les systèmes de fichiers pris en charge incluent FAT32, FAT16 et FAT12 (mais pas exFAT ni NTFS). Les tables de partition prises en charge comprennent les formats MBR et GPT. Contrairement au BIOS, l'UEFI n'exige pas que le secteur d'amorce se trouve à un endroit particulier.

Architecture UEFI

De nombreuses cartes mères reposent encore sur un firmware hybride reposant sur le paquetage CSM (Compatiblity Support Module) rendant exploitables les anciennes interruptions du BIOS pour certains services.

La terminologie officielle de l'UEFI catégorise six états distincts dans des processus de démarrage du système d'exploitation :

  • SEC (Security) pour l'exécution des processus d'authentification et de contrôle d'intégrité (SecureBoot, mot de passe, token USB) ;
  • PEI (Pre EFI Initialization) pour l'initialisation de la carte mère et du chipset. Passage du processeur en mode protégé ;
  • DXE (Driver Execution Environment) pour l'enregistrement de tous les pilotes. Le routage par un dispatcher des demandes issues des applications EFI comme un chargeur de démarrage ;
  • BDS (Boot Dev Select) pour un gestionnaire de démarrage comme grub ;
  • TSL (Transient System Load) pour la phase transitoire où le système d'exploitation est chargé. Les services EFI seront clos via la fonction ExitBootServices(), pour passer la main au système d'exploitation ;
  • RT (RunTime) quand le système d'exploitation a pris la main. Le seul moyen d'interagir avec le firmware est alors de passer par les variables EFI stockées dans la NVRAM.

Systèmes d'exploitation
  • Les systèmes fondés sur Linux sont capables de gérer l'UEFI au démarrage depuis 2000 en utilisant le chargeur d'amorçage Elilo. Il peut être utilisé par les plates-formes IA-64, IA-32 et offre une prise en charge pour le x86-64 depuis . GRUB supporte l'EFI depuis la version 1.94[2].
  • Le noyau Linux prend en charge l'EFI depuis la version 2.4.20[3], et peut s'amorcer directement en tant qu'exécutable EFI[4] depuis la version 3.3.5[5].
  • HP-UX utilise l'EFI sur ses systèmes IA-64 depuis 2002.
  • Apple a, quant à lui, adopté l'EFI sur ses ordinateurs à base de processeurs Intel. Mac OS X v10.4 Tiger pour Intel, Mac OS X v10.5 Leopard, Mac OS X v10.6 Snow Leopard et Mac OS X v10.7 Lion prennent entièrement en charge l’EFI. La version de l'EFI implémentée sur les ordinateurs Apple diffère néanmoins quelque peu du standard EFI, ce qui fait que la plupart des ordinateurs Apple ne permettent pas de démarrer sous Windows en mode EFI (Sous Boot Camp, seul un démarrage émulant l'ancien BIOS des PC fut au départ possible, empêchant alors Windows d'accéder au disque dur de l'ordinateur Apple en mode SATA, et réduisant donc les performances disques quand l'ordinateur était démarré sous Windows). Avec la sortie du MacBook Air mi-2013, Windows 8 et les versions postérieures furent pleinement supportées en démarrage EFI.
  • Microsoft Windows :
    • Les versions Itanium de Windows 2000 supportaient l'EFI 1.1 en 2002 ;
    • Windows Server 2003 pour IA64, Windows XP 64-bit et Windows 2000 Advanced Server Limited Edition, fondés sur l'Intel Itanium supportent l'EFI ;
    • Microsoft Windows Vista contient un système de gestion de l'UEFI depuis la version SP1. Microsoft Windows Server 2008, fondé sur le noyau de Windows Vista SP1, gère également les plates-formes UEFI. Cependant, à cause du Graphics Output Protocol (GOP) des UEFI, un système Windows Vista/7 ne peut pas démarrer sans la couche CSM/Legacy, ce qui revient à l'utilisation par émulation d'un BIOS. Windows Vista n'est donc techniquement pas compatible avec l'UEFI pur (classe 3, sans CSM/legacy)
    • Windows 8, 8.1 et 10 démarrent sous UEFI, mais exigent de définir depuis Windows qu'on effectuera le prochain amorçage vers un autre système : il n'est pas possible d'intercepter l'UEFI comme on interceptait autrefois le BIOS (pour booter Linux depuis un disque USB, par exemple), la raison invoquée étant la sécurité.

Fonctionnalités

Gestion des disques

Outre le partitionnement classique par MBR (limité à 2,2 To), UEFI gère pour les disques, un nouveau système de partitionnement nommé GPT (globally unique identifier partition table). Le GPT permet 128 partitions principales sur un support de capacité allant jusqu'à 9,4 Zo (zettaoctet, milliard de téraoctets). UEFI permet ainsi le démarrage sur des disques de 2,2 To et plus.

Grâce à la gestion bas niveau des disques, le clonage de disques est possible sans passer par le système d’exploitation, ce qui facilite considérablement les copies de disques hébergeant plusieurs systèmes d'exploitation.

Shell UEFI

UEFI fournit un environnement shell proche de ce que l'on trouve dans un shell Unix. Il peut être utilisé pour lancer d'autres applications UEFI, ce qui inclut des UEFI boot loaders. Il est possible d'obtenir une grande variété d'informations sur le système et le firmware, modifier des variables ou éditer des fichiers texte, de même qu'écrire ou lancer des fichiers scripts portant l'extension .nsh.

Les méthodes pour lancer le Shell UEFI dépendent du constructeur et du modèle de carte mère. Le plus souvent, il y a une option dans le firmware pour le lancer directement. Pour les versions compilées pour x86-64, il y a besoin d'un fichier <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Il faut utiliser la commande bcfg pour modifier le shell associé.

La plupart des commandes sont insensibles à la casse, mais pas toujours les chemins et noms de fichiers, suivant le type de système de fichiers utilisé. Utiliser la commande help -b permet d'avoir un affichage de l'aide page par page. L'option -b se retrouve sur la plupart des commandes pour avoir un affichage page par page. Le caractère > peut être utilisé pour rediriger le flux de sortie de la commande dans un fichier texte. Par exemple la commande help > aide.txt écrit l'aide dans le fichier aide.txt.

Le code source du Shell UEFI peut être téléchargé sur la page du projet TianoCore.

Lancement sécurisé (secure boot)

Depuis la version 2.3.1, l'UEFI intègre une fonctionnalité n'autorisant le démarrage qu'aux systèmes d'exploitation reconnus. Cette fonctionnalité vise à interdire le démarrage d'un système d'exploitation corrompu notamment par un virus ou un rootkit. Lors de sa sortie cette fonctionnalité posait problèmes avec certaines distributions de Linux qui n'étaient pas compatibles.

En mode « lancement sécurisé » (secure boot), l'UEFI utilise un mécanisme de vérification par signatures numériques. Le micrologiciel interdit tout chargement de driver ou de noyau dont la signature ne correspondrait pas à celle gravée en ROM.

Boot sécurisé et logiciel libre

Dans le monde du logiciel libre, l'EFF[6] et Linus Torvalds[7] ont dénoncé comme anormale cette fonctionnalité « entravant l'installation et l'utilisation de tout système d'exploitation concurrent de Windows », Torvalds critiquant les compromis acceptés par Red Hat et Canonical pour pouvoir installer Linux sur les machines où le boot sécurisé est activé (achat d'une clé de sécurité).

Mi-2012, toutes les distributions n'avaient pas adopté la signature du système d'exploitation[8], certaines ne pouvant l'adopter en raison de leur statut.

Il existe depuis début 2013 deux bootloaders signés par Microsoft, et donc reconnus par les PC certifiés Windows 8 : Shim[9] et Linux Foundation Secure Boot System[10].

DistributionPosition relative au Secure Boot
UbuntuSupporté depuis les versions 12.10[11] et 12.04.2 LTS[12]
FedoraSupporté depuis la version 18[13]
openSUSESupporté depuis la version 12.3[14]
RHELSupporté depuis la version 7[15]
DebianSupporté depuis la version 10[16]
OpenBSDFaute de collaboration avec Microsoft[17], cette fonction n'est pas supportée.

Windows

Windows 8 de Microsoft supporte de façon optionnelle[18] le secure boot grâce à une signature numérique transmise aux constructeurs de cartes mères.

Selon le programme de certification Windows[19], les appareils non ARM doivent obligatoirement proposer deux modes secure boot, « Standard » et « Custom » dans lequel l'utilisateur peut non seulement ajouter ou supprimer des signatures supplémentaires mais également désactiver le secure boot (présence physique de l'utilisateur requise).

Au contraire, sur les appareils ARM, Microsoft interdit la désactivation du secure boot aux constructeurs[19].

Cas d'Ubuntu

Le forum Ubuntu présente deux façons de démarrer cette distribution[20] :

  1. sans se soucier de l'UEFI ;
  2. ou en la faisant reconnaître par l'UEFI.

La première solution peut, en principe, fonctionner du fait qu'elle court-circuite l'UEFI avec une autre distribution Linux, installée sur un SSD connecté par USB3, eSATA ou USB2 par exemple. Cette disposition permettant un accès non autorisé (éventuellement malveillant) demandera soit un accès physique surveillé ou mis sous clé, soit un chiffrement des informations du disque avec par exemple TrueCrypt ou équivalent, assorti de sauvegardes rigoureuses.

Critiques et polémiques

Compatibilité des systèmes d'exploitation alternatifs

Tous les systèmes d'exploitation ne supportent pas le secure boot.

Si l'utilisateur ne désactive pas le secure boot dans l'UEFI, celui-ci peut empêcher l'utilisation de certains systèmes d'exploitation libres ou alternatifs.

Dans le monde du logiciel libre, plusieurs voix s’élèvent pour dénoncer le fait que la signature émanerait principalement, ou même exclusivement, de Microsoft, et non d'autres éditeurs de logiciels[réf. souhaitée].

John Sullivan

John Sullivan (FSF Executive Director[21]) ne croyait pas que la raison principale du « secure boot », qu'il appelle plutôt boot exclusif, soit la sécurité[22] mais bien de rendre plus difficile l'installation de systèmes d'exploitation concurrents (non signés ou n'ayant pas une signature acceptée par le constructeur du matériel)[23],[24]et a créé une polémique.

Microsoft et Intel ont déclaré que les utilisateurs comme les fabricants peuvent désactiver cette fonctionnalité sur les ordinateurs sous UEFI qui le permettraient[25].

Linus Torvalds

Linus Torvalds, lui, a déclaré initialement que le simple achat d'un certificat numérique à 99 $ pour couvrir toute une distribution ne lui semblait pas être une « énorme affaire »[17].

Notes et références
  1. (en)Memebership list, sur uefi.org, consulté le 31 janvier 2018.
  2. (en) « Log of /grub2/ChangeLog », sur gnu.org, 4 juin 2006 (consulté le 1er octobre 2013).
  3. (en) « ChangeLog-2.4.20 », sur kernel.org, 28 novembre 2002 (consulté le 1er octobre 2013).
  4. (en) « The EFI Boot Stub », sur kernel.org (consulté le 12 décembre 2019).
  5. (en) « ChangeLog-3.3.5 », sur kernel.org, 7 mai 2012 (consulté le 12 décembre 2019).
  6. « Secure boot et Linux : les critiques montent et la FSF pétitionne », sur zdnet.fr, 31 janvier 2013 (consulté le 6 mai 2013).
  7. « Secure boot et Linux : "ce n'est pas un concours de pipes", enrage Linus Torvalds », sur zdnet.fr, 27 février 2013 (consulté le 6 mai 2013).
  8. « Secure Boot : Canonical aura sa propre clé de sécurité pour Ubuntu », sur pcinpact.com, 27 juin 2012 (consulté le 30 juin 2012).
  9. (en) « Secure Boot bootloader for distributions available now », sur mjg59.dreamwidth.org, 30 novembre 2012 (consulté le 14 février 2013).
  10. (en) « Linux Foundation Secure Boot System released », sur blog.hansenpartnership.com, 8 février 2013 (consulté le 14 février 2013).
  11. (en) « Ubuntu 12.10 (Quantal Quetzal) released! », sur ubuntu-news.org (consulté le ).
  12. (en) « Ubuntu 12.04.2 LTS released », sur ubuntu-news.org (consulté le ).
  13. (en) « Release Notes », sur docs.fedoraproject.org (consulté le ).
  14. (en) « openSUSE:UEFI », sur en.opensuse.org (consulté le ).
  15. (en) « Unified Extensible Firmware Interface (UEFI) Secure Boot », sur access.redhat.com (consulté le ).
  16. (en) « SecureBoot », sur wiki.debian.org (consulté le ).
  17. « OpenBSD accuse Red Hat et Canonical de traîtrise », sur lemondeinformatique.fr, 27 juillet 2012 (consulté le 30 juillet 2012).
  18. Pour Microsoft, le Secure Boot lié à l'UEFI ne constitue pas un problème avec Windows 8., sur generation-nt.com du 23 septembre 2011, consulté le 26 novembre 2017
  19. (en) « Microsoft confirms UEFI fears, locks down ARM devices » softwarefreedom.org, 12 janvier 2012.
  20. uefi, sur ubuntu-fr.org, consulté le 26 novembre 2017
  21. Richard M. Stallman, President, sur fsf.org, consulté le 26 novembre 2017
  22. (en)John Sullivan, Free Software Foundation recommandations for free operating system distributions considering Secure Boot : « Without a doubt, this is an obstacle we don't need right now, and it is highly questionable that the security gains realized from Secure Boot outweigh the difficulties it will cause in practice for users trying to actually provide for their own security by escaping Microsoft Windows. »
  23. (en) « UEFI secure booting », Site web de Matthew Garrett, développeur Red Hat, 20 septembre 2011.
  24. (en) « UEFI secure booting (part 2) », Site web de Matthew Garrett, développeur Red Hat, 23 septembre 2011.
  25. (en) « Protecting the pre-OS environment with UEFI », blogs.msdn.com, 22 septembre 2011.

Voir aussi

Solution alternative

Liens externes
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.