« UEFI » : différence entre les versions

Un article de Wikipédia, l'encyclopédie libre.
Navigation interactive dans l’historique
← Modification précédenteModification suivante →
Contenu supprimé Contenu ajouté
VisuelWikicode
Karl1263 (discuter | contributions)
25 357 modifications
m WPCleaner v1.33 - Correction syntaxique (Section « Notes et références » manquante)
→‎Shell UEFI : correction redirection, il faut un espace après le '>'
Ligne 49 : Ligne 49 :
Les méthodes pour lancer le Shell UEI dépendent du constructeur et du modèle de carte mère. Le plus souvent, il y a une option dans le {{Langue|en|texte = firmware}} pour le lancer directement. Pour les versions compilées pour x86-64, il a besoin d'un fichier <code><EFI_SYSTEM_PARTITION>/SHELLX64.EFI</code>. Il faut utiliser la commande <code>bcfg</code> pour modifier le shell associé.
Les méthodes pour lancer le Shell UEI dépendent du constructeur et du modèle de carte mère. Le plus souvent, il y a une option dans le {{Langue|en|texte = firmware}} pour le lancer directement. Pour les versions compilées pour x86-64, il a besoin d'un fichier <code><EFI_SYSTEM_PARTITION>/SHELLX64.EFI</code>. Il faut utiliser la commande <code>bcfg</code> pour modifier le shell associé.


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


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

Version du 6 octobre 2014 à 14:49

Page d’aide sur l’homonymie

Pour les articles homonymes, voir EFI.

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

La norme Unified Extensible Firmware Interface (UEFI, « Interface micrologicielle extensible unifiée ») définit un logiciel intermédiaire 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. Elle fait suite à EFI (Extensible Firmware Interface), conçue par Intel pour les processeurs Itanium.

L'UEFI offre plusieurs avantages par rapport au BIOS, comme des fonctionnalités réseau intégrées en standard, une interface graphique haute résolution, une gestion intégrée des installations multiples de systèmes d’exploitation et l'affranchissement de la limite des disques à 2,2 To.

Le BIOS était écrit en assembleur. L'UEFI est écrit en C, ce qui en rend la maintenance plus aisée et est compatible avec les coûts relativement bas 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 bits et 64 bits) et ARM.

AMD, American Megatrends, Apple, Dell, HP, Intel, IBM, Insyde, Microsoft et Phoenix Technologies sont les promoteurs de l’UEFI Forum qui définit 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.

Généralités

Une des fonctions principales d'UEFI est l'amorçage d'un système d'exploitation, rôle réservé jusque là au BIOS.

Les spécifications de l'UEFI définissent un « boot manager » dont le rôle est de charger l’OS loader et les drivers nécessaires au démarrage. Les OS Loader sont une classe d'application UEFI stockés sous forme de fichiers sur un système de fichiers accessible par firmware. Les systèmes de fichiers pris en charge incluent FAT32, FAT16 et FAT12. Les tables de partition prises en charges comprennent les formats MBR et GPT. Contrairement au BIOS, l'UEFI ne repose pas sur un secteur d'amorce.

Architecture UEFI

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

La terminologie officielle de l'UEFI distingue 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ée. Les services EFI seront clos via la fonction ExitBootServices(), pour passer la main au système d'exploitation ;
  • RT (RunTime) quand c'est le système d'exploitation qui a pris la main. Le seul moyen d'interagir avec le firmware est désormais de passer par les variables EFI qui sont stockées dans la NVRAM.

Systèmes d'exploitation

  • Les systèmes basés sur Linux sont capables de gérer l'EFI 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 juillet 2007. GRUB supporte l'EFI depuis 2006[2].
  • Linux prend en charge l'EFI depuis sa version 2.4.20[3], et peut s'amorcer directement en tant qu'exécutable EFI depuis la version 3.3[4].
  • HP-UX utilise l'EFI sur ses systèmes IA-64 depuis 2002.
  • Apple a, quant à lui, adopté l'EFI sur ses ordinateurs Apple à 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 qui émule l'ancien BIOS des PC est actuellement possible, ce qui empêche à Windows d'accéder au disque dur de l'ordinateur Apple en mode SATA, et réduit donc les performances disques lorsque l'ordinateur est démarré sous Windows). Cependant depuis la sortie du MacBook Air mi-2013, Windows 8 est pleinement supporté en démarrage EFI[5].
  • Microsoft Windows :

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 peut se faire sans passer par le système d’exploitation, ce qui facilite les copies de disques hébergeant plusieurs systèmes d'exploitation.

Shell UEFI

UEFI fournit un environnement shell très proche de ce que l'on trouve dans un shell Unix. Il peut être utilisé pour lancer d'autre applications UEFI, ce qui inclus des UEFI boot loaders. Vous pouvez obtenir une grande variétés d'informations sur le système et le firmware. Modifier des variables ou éditer des fichiers texte. On peut écrire ou lancer des fichiers scripts qui sont nommées avec l'extension .nsh.

Les méthodes pour lancer le Shell UEI 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 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 ne sont pas sensible à la casse. Mais cela peut être le cas pour les chemins et les 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.

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.

Secure boot 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 secure boot est activé.

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].

Distribution Position relative au Secure Boot
Redhat Linux Utilisation confirmée, clé fournie par Microsoft pour 99 $ USD[11]
Ubuntu Utilisation confirmée, clé fournie par Microsoft pour 99 $ USD[11]
OpenSuse Position non arrêtée en juin 2012[12]
OpenBSD Faute de collaboration avec Microsoft[11], cette fonction n'est pas supportée.
Debian Debian, qui ne constitue pas une entité commerciale mais une communauté, ne peut acheter une signature quelconque à une entité commerciale telle que Microsoft[13]. En outre, les statuts de la distribution sont très restrictifs : l’emploi de marques commerciales y est interdit. Enfin, l'emploi d'une clef secrète empêcherait la modification du code par une autre entité que Debian et contreviendrait à la quatrième liberté fondamentale du logiciel libre (la liberté de modification).

Windows

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

Selon le programme de certification Windows 8[15], 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[15]. Richard Stallman considère que cette pratique devrait être illégale[16].

Cas d'Ubuntu

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

  1. sans se soucier de l'UEFI ;
  2. ou en le 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, par exemple installée sur un SSD connecté par USB3, eSATA ou USB2. 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, assorti de sauvegardes rigoureuses.

Critiques

Complexité

Dès juillet 2006, Linus Torvalds avait émis de premières critiques sur l'UEFI, car celui-ci complique l'étape d'amorçage de la machine en se substituant au BIOS[18].

Compatibilité des Systèmes d'exploitation alternatifs

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

Ainsi, 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, de nombreuses 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[19]) ne croit pas que la raison principale du « secure boot », qu'il appelle plutôt boot exclusif, soit la sécurité[20] 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)[21],[22].

Microsoft a déclaré que les utilisateurs comme les fabricants peuvent désactiver cette fonctionnalité sur les ordinateurs sous UEFI qui le permettraient[23].

La Free Software Foundation, va plus loin en demandant que par norme, contrat ou loi les fabricants soient mis en demeure de permettre à l'utilisateur de décider de ses modalités de secure boot dans leurs ordinateurs (autre clef publique ou désactivation pure et simple)[24]. La fondation a donc lancé une campagne sur cette problématique le 13 octobre 2011[24].

Ward Vandewege

Pour les utilisateurs ordinaires, d'après Vandewege (FSF Chief Technology Officer[19]), coreboot est aussi une protection contre les technologies dites de Gestion des droits numériques, telles que la fonction d'isolation de l'EFI d'Intel, qui contrôle l'accès au matériel. Selon Vandewege, l'introduction de telles fonctions représente une menace pour la vie privée et les droits des consommateurs, car quiconque contrôle le BIOS contrôle l'ordinateur. Si vous contrôlez le BIOS, vous pouvez rejeter tout programme qui se charge après le BIOS[25].

Linus Torvalds

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

Notes et références

  1. ↑ (en)Site de l'UEFI.
  2. ↑ http://cvs.savannah.gnu.org/viewvc/grub2/ChangeLog?revision=1.236&root=grub&view=markup
  3. ↑ https://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.20
  4. ↑ https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/efi-stub.txt?id=HEAD
  5. ↑ http://www.journaldulapin.com/2013/06/27/macbook-air-2013-totalement-compatible-windows-8/
  6. ↑ http://www.zdnet.fr/actualites/secure-boot-et-linux-les-critiques-montent-et-la-fsf-petitionne-39786795.htm
  7. ↑ http://www.zdnet.fr/actualites/secure-boot-et-linux-ce-n-est-pas-un-concours-de-pipes-enrage-linus-torvalds-39787681.htm
  8. ↑ « Choix des distributions concernant Secure Boot » pcinpact.com, 27 juin 2012.
  9. ↑ (en) Secure Boot bootloader for distributions available now.
  10. ↑ (en) Linux Foundation Secure Boot System.
  11. ↑ a b c et d « OpenBSD accuse Red Hat et Canonical de traîtrise », lemondeinformatique.fr, 27 juillet 2012.
  12. ↑ (en) Opensuse et secure boot.
  13. ↑ FOSDEM 2013-Miscellaneous track-UEFI SecureBoot- Questions et réponses.
  14. ↑ http://www.generation-nt.com/windows-8-linux-secure-boot-uefi-actualite-1260501.html
  15. ↑ a et b (en) « Microsoft confirms UEFI fears, locks down ARM devices » softwarefreedom.org, 12 janvier 2012.
  16. ↑ (en) Roy Schestowitz, « Speaks About UEFI », sur bytesmedia.co.uk, (consulté le ).
  17. ↑ http://doc.ubuntu-fr.org/efi
  18. ↑ (en)Linus On The Extensible Firmware Interface, 24 juillet 2006.
  19. ↑ a et b http://www.fsf.org/about/staff-and-board
  20. ↑ (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. »
  21. ↑ (en) « UEFI secure booting », Site web de Matthew Garrett, développeur Red Hat, 20 septembre 2011.
  22. ↑ (en) « UEFI secure booting (part 2) », Site web de Matthew Garrett, développeur Red Hat, 23 septembre 2011.
  23. ↑ (en) « Protecting the pre-OS environment with UEFI », blogs.msdn.com, 22 septembre 2011.
  24. ↑ a et b (en) « UEFI "Secure Boot" and Microsoft Windows 8: The danger for free software », fsf.org, 13 octobre 2011.
  25. ↑ (en)LinuxBIOS ready to go mainstream, 7 décembre 2006.

Voir aussi

Solution alternative

Références externes

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=UEFI&oldid=108006566 ».