N. D. M. : Cette dépêche est issue d’un journal, merci à son auteur.
Qu’il semble loin le temps, béni pour certains, maudits pour d’autres, où il était nécessaire de connaître les IRQ et DMA de sa machine pour l’utiliser, où, loin du plug’n’play, le matériel se contentait de laisser l’humain configurer…
Puis vint le plug’n’play, son compagnon l’ACPI permettant de lister le matériel et de le configurer magiquement. Mais toujours, au sein de la machine, un petit logiciel, le BIOS.
Sommaire
- Plongeons‐nous dans les entrailles de nos machines
- Naissance d’EFI
- Voyons un peu comment est construit un EFI
- Concrètement, comment identifier un EFI ?
- Bootons en EFI
- Le shell EFI
- efilinux
- Remerciements
Plongeons‐nous dans les entrailles de nos machines
Le BIOS est, de manière assez surprenante, l’élément probablement à l’origine du succès de l’IBM PC. En effet, le BIOS, l’élément primitif indispensable au démarrage de la machine, a été mis, non pas sur les disques de boot, mais en ROM sur la carte mère.
Quelques années plus tard, après un peu de rétro‐ingénierie, des fabricants ont pu commencer à vendre des clones de PC compatibles, basés sur une ré‐implémentation du BIOS. Le BIOS est moche, clairement ; très basique, très crade. Mais il faisait son travail, il fournit une abstraction très primitive au matériel. On pouvait presque écrire un OS uniquement en faisant des appels au BIOS, comme DOS.
Les appels au BIOS sont très simples : il s’agit tout bêtement d’une série d’interruptions matérielles. À travers l’IRQ 0x10, on peut donner différentes instructions à la carte graphique, via le registre AH : défilement (scrolling), changement de mode et des couleurs. L’IRQ 0x13 permet de contrôler les disques.
Naissance d’EFI
Mais avec l’évolution du matériel, les limites sont apparues : le BIOS utilise un mode 16 bits, ne lui permettant pas d’adresser toute la RAM, l’amorçage par le réseau ou par CD est apparu, l’USB est arrivé. Récemment toutefois, nous avons atteint une limite très difficile à surmonter : la table des partitions gérée par le BIOS ne permet pas d’exploiter des disques de plus de 2 Tio.
En parallèle, depuis la fin des années 90, Intel avait développé, en partenariat avec HP, l’architecture Itanium, pour laquelle l’utilisation du BIOS n’était pas envisageable. Ainsi, Intel développa un outil moderne, puissant, flexible, simple et unanimement repris : l’EFI.
Bon, OK, en vrai c’est plus compliqué : en 1994, l’IEEE avait déjà standardisé Open Firmware, une solution multi‐plate‐forme et acceptée pour accomplir une tâche similaire au BIOS. Utilisé sur les machines Sun, Apple, IBM, c’est un outil qui a fait ses preuves et continue à les faire.
Mais pour Intel, Open Firmware n’est pas acceptable. Officiellement, c’est parce que l’Open Firmware duplique l’ACPI en fournissant son propre arbre de périphériques. Mais depuis, le projet OLPC a prouvé qu’en fait, c’est possible. Par contre dans EFI, il y a un arbre de périphériques potentiellement différent de celui de l’ACPI (et vous êtes loin de la fin de ce journal, hein).
EFI est décrit dans une spécification, contrairement au BIOS, qui n’a jamais eu de telle documentation : 2 210 pages, plus les 800 pages d’ACPI. Mangez la spécification, c’est du bon.
Bien sûr, EFI a évolué lui aussi : la norme EFI a cessé d’évoluer et l’UEFI fut créé à partir d’EFI 1.10. UEFI est une évolution d’EFI contrôlée par le Forum UEFI et non plus par Intel.
En 2007, la version 2.1 d’UEFI a apporté la cryptographie, l’authentification réseau, la possibilité de construire une interface graphique. Ouais, on parle toujours de « firmware ».
Voyons un peu comment est construit un EFI
On a en fait trois couches dans EFI. Au cœur, se trouve le PEI, Pre‐EFI Initialization. Responsable de l’initialisation très bas niveau, comme le contrôleur mémoire (truc super‐tordu mine de rien, cf. les présentations des auteurs de coreboot), il gère à la fois le tout début de l’allumage de la machine, mais aussi la sortie de veille. Une fois qu’il a fait son travail, il laisse la main à la deuxième couche et disparaît.
La deuxième couche se nomme DXE, Driver eXecution Environment. C’est ce que l’on voit finalement du firmware. C’est un élément indépendant du matériel, capable de charger des pilotes et fournissant des interfaces génériques et normalisées aux applications souhaitant l’utiliser.
Enfin, la troisième couche, les applications EFI, en majeure partie les bootloaders donc… Alors, si vous trouvez que ça ressemble à BIOS + OS + applications, difficile d’argumenter tellement ça semble exact ! Au passage, a priori, une application EFI dépend de l’architecture : elle sera x86, x86-64, ia64.
Concrètement, comment identifier un EFI ?
Hum, c’est une bonne question. Je dispose depuis quelques jours d’un ordinateur portable ASUS utilisant un magnifique UEFI. Mais par défaut, une émulation du BIOS est présente, permettant de lancer un GRUB sans soucis. Pire encore, par défaut, le boot EFI n’est même pas activé sur les clés USB, par exemple.
J’avoue ne pas avoir trouvé de solution depuis GNU/Linux pour le savoir. À vrai dire, c’est le but de l’émulation du BIOS, non ? Et le Windows n’a pas vécu assez longtemps (0 seconde) pour vérifier.
Seul un passage par l’interface de configuration du firmware (ce que, par abus de langage, on appelait BIOS) prouve que l’on est face à une machine EFI. Heureusement, ici, pas d’interface graphique qui bouge dans tous les sens. Nous avons une interface sobre, classique, contrôlée au clavier, avec des options comme « UEFI Boot », pour nous mettre sur la voie.
Bootons en EFI
Dans mon ignorance, j’ai installé ma Debian classiquement, sans réfléchir : 256 Mio pour un « /boot » en ext3, le reste en volume physique LVM, un GRUB, et ça roule ! Et je ne peux donc pas profiter d’un boot EFI : le chargeur d’amorçage (boot loader) pour EFI doit être stocké sur une partition pour laquelle un pilote est chargé. Ne pouvant ajouter de pilote ext3 dans mon firmware, je me vois contraint d’avoir une partition FAT pour le chargeur d’amorçage !
Mon premier objectif n’étant pas la destruction de mon amour propre et de ma distribution, j’opte donc pour une solution plus sage : booter en EFI sur une clé USB. Le boot EFI 100 % natif top moumoute viendra plus tard.
Préparons donc une clé USB à booter en EFI. Mais que mettre dessus ? Mettre un GRUB classique pour un BIOS, je sais faire. Mais un EFI ne mange pas de ce pain.
Ma clé USB était une clé USB classique, partitionnée avec une table de partitions DOS et une seule partition FAT32. Je décidai, pour l’expérience, de la maltraiter un peu. Mais, normalement, vous n’avez pas à la maltraiter à ce point.
Donc maltraitons‐la : passons‐la en GPT, nouveau format de table de partitions, permettant de passer outre la limite des 2 Tio (indispensable sur une clé de 8 Gio). Pour ce faire, [[parted]] est notre ami, avec la commande « mklabel gpt » (ce journal ne visant pas à faire de vous un expert de parted, je n’irai pas plus loin).
Il suffit donc d’avoir une table des partitions valide, comprise du BIOS, et d’y glisser subtilement une partition FAT. Faisons donc. Mais que mettre sur cette partition FAT, et où ? C’est là où j’ai perdu le plus de temps finalement.
J’avais expliqué tantôt que l’EFI charge une application, la plupart du temps un chargeur d’amorçage. Mais je ne suis pas fou, je ne vais pas directement tenter GRUB. Tentons plus simple, plus utile aussi, pour une clé USB : l’EFI shell (explications dans un paragraphe, j’ai pas trouvé mieux comme organisation).
Le projet tiano-core, une implémentation libre du cœur d’UEFI, nous fournit ce shell à l’adresse suivante :
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UEFI_Shell.
Mettons ce shell sur la clé USB. Pour cela, je crée un dossier EFI, et je mets dedans le fichier « shell.efi ». Mais ça ne marche pas (n’essayez pas).
En effet, il faut mettre un bon nom au fichier. Le fichier d’amorçage, dans le cas d’une clé USB en x86-64, doit être à l’emplacement suivant : « \EFI\boot\bootx64.efi ».
Notez l’utilisation de la notation x64 pour parler d’x86-64, que l’on nomme amd64, x64 est la notation de Sun et Microsoft. Et la contre‐oblique (anti‐slash) est de mise en EFI.
Une fois le fichier mis sur la clé et la machine démarrée, on se retrouve dans le grandiose EFI shell !
Le shell EFI
Le premier qui dit que ça ressemble à DOS, gagne un cadeau Bonux. Notons tout d’abord la liste des périphériques bloc détectés, affichée en haut de l’écran au lancement du shell. Un conseil : ajoutez immédiatement ce logiciel dans votre trousse à outils pour dépanner des machines. Je ne plaisante pas : il me semble être tout simplement indispensable, pour les futurs EFI bogués, de disposer de cet outil et des quelques utilitaires qu’il propose.
Vous voici maintenant devant un shell à l’invite fort engageante, couleur jaune sur un fond noir :
Shell>
Voici les commandes qui m’ont semblé intéressantes (je ne m’amuserai plus à recopier tout le résultat des commandes) :
-
help :l’indispensable ; -
drivers :liste l’ensemble des pilotes chargés dans l’UEFI. Comme ça, quand votre clé USB 4 ne fonctionnera pas, vous pourrez charger un pilote USE 4 depuis votre clé USB 3 ; -
devices :liste les périphériques connus, mais c’est moins joli que devtree.
Sur mon PC portable, j’ai 8 périphériques :
- fs0 alias hd22b0d0b (après plusieurs reboots : cet identifiant est dynamique) alias blk0 : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)/HD(Part1,Sig64ED66EC-D248-412A-AEEB-B0ECA830E264)
- blk1 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part1,Sig0003AC8C)
- blk2 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)/HD(Part2,Sig0003AC8C)
- blk3 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(0,0)
- blk4 : Acpi(PNP0A03,0)/Pci(1F|2)/Sata(2,0)
- blk5 : Acpi(PNP0A03,0)/Pci(1D|0)/Usb(1,0)/Usb(3,0)
OK, facile de deviner : fs0 est la partition 1 de la clé USB. Mais que faire d’autre maintenant ?
Mouais… Pas super fun. Au passage, vous verrez des commandes pour le support de DHCP, d’IPv4. Rien pour IPv6 par contre. Ça c’est l’avenir.
Explorons donc plutôt le système de fichiers. Vous vous souvenez bien de DOS ? Si oui, c’est facile :
fs0:
Et voilà, vous êtes dans le disque fs0… Puis, vous pouvez utiliser les bonnes vieilles commandes DOS du type « cd », « dir » (ou « ls », ouf !), type (et pas « cat »)…
Mais passons à plus rigolo : bootons un Linux depuis EFI !
efilinux
efilinux est une solution très récente et très simple pour amorcer un Linux depuis EFI. C’est le LILO d’EFI, en quelque sorte. Il est disponible en paquet Debian, et contient principalement le fichier suivant : « /usr/lib/efilinux/efilinux.efi ».
On va donc mettre « efilinux.efi » sur la clé USB et l’accompagner d’un vmlinuz et de l’initrd correspondant.
On se retrouve donc avec dans `« fs0:/EFI » les fichiers suivants :
-
« boot\bootx64.efi », le shell ; -
« vmlinuz-3.1.0-rc7-amd64 »; -
« initrd-3.1.0-rc7-amd64 »; -
« efilinux.efi ».
La méthode d’amorçage est très très simple :
fs0:
cd EFI
efilinux.efi -f 0:\EFI\vmlinuz-3.1.0-rc7-amd64 root=/dev/mapper/asus--laptop-root ro initrd=0:\EFI\initrd-3.1.0-rc7-amd64Et voilà !
Vous avez amorcé votre premier noyau avec un système EFI « pur ».
Et vous verrez la différence :
$ dmesg | grep -c -i efi
308Contre 0 ou 1 auparavant…
Devant la longueur de ce journal, il est urgent d’attendre avant de continuer. Prochain épisode : je remplace GRUB par un gestionnaire d’amorçage UEFI… Puis, je code une appli UEFI !
Remerciements
Merci à ASUS de rembourser Windows, sans me priver de ma machine…
Merci à Matthew Garrett pour son magnifique blog et ses grandes explications sur EFI…
Et merci à Debian pour exister…
P.‐S. : je ne peux garantir que tout ceci fonctionne sur une machine Apple, tout simplement parce qu’elles utilisent une solution bâtarde entre EFI et UEFI, avec un comportement souvent différent de ce que l’on voit sur les machines des autres constructeurs.
Aller plus loin
- Journal à l’origine de la dépêche (1470 clics)
# BIOS : interruptions *logicielles*
Posté par ChrisJ (site web personnel) . Évalué à 10.
Non justement, ce sont des interruptions logicielles, car elles sont déclenchées en logiciel (instruction
INT). Les interruptions matérielles sont déclenchées par des lignes d'interruption (des broches du processeur sur lesquelles on applique une valeur logique déterminée, dans le cas le plus simple).[^] # Re: BIOS : interruptions *logicielles*
Posté par jokoe . Évalué à 3.
Que veux-tu... On apprend plus l'assembleur de nos jours ma bonne dame...
[^] # Re: BIOS : interruptions *logicielles*
Posté par Pinaraf . Évalué à 3.
Ou on rédige à minuit avec des gens qui vous emmerde sur jabber…
Et pour mutualiser la réponse : merci pour les corrections sur GPT et le BIOS, c'est effectivement un argument très répandu, mais je ne le savais pas aussi faux…
# Tianocore
Posté par alpha_one_x86 (site web personnel) . Évalué à 5.
Moi j'ai déjà prévu le coup, j'ai depuis longtemps mit grub2 efi + grub2 dos, et j'ai tester les 2 avec qemu efi (tianocore sous projet ovmf) et qemu dos (le normal), je doit avouer, d'avoir sa boite à outils d'application efi sous la main c'est super.
Surtout un grub2 avec son shell.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Tianocore
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Note sur tianocore: il intégre un certain nombre de chose simpa, telque un miniexplorateur de fichier pour parcourir graphiquement (à la ncurse) les partitions.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# pfiou
Posté par antistress (site web personnel) . Évalué à 10.
ça me dépasse
N'oublions de citer Linus au sujet de l'UEFI "c'est de la merde" (enfin il a été un peu plus dissert : http://kerneltrap.org/node/6884 )
# bios et succès du PC
Posté par Guillaume Knispel . Évalué à 10.
Le BIOS n'est pas le seul élément a être à l'origine du succès des PC. Déjà il n'y avait absolument pas besoin de le reverse car le code source commenté était disponible dans un manuel technique à $60. Ensuite ce manuel contenait aussi carrément les schématiques du PC. L'ouverture du hard et du soft a permit les clones (par la bonne compatibilité des implémentations concurrentes, il ne s'agissait pas de logiciel libre), une facilité de conception + bonne compatibilité des extensions, mais aussi des applications vu la précision des documentations (et à l'époque (presque?) toutes les applications attaquaient directement le bios et/ou le hard à un endroit ou à un autre).
[^] # Re: bios et succès du PC
Posté par esdeem . Évalué à 8.
A l'époque ce genre de documentations était courant.
J'ai encore les schémas et la doc des mes Amigas. C'est tellement complet que tu peux recréer la machine rien qu'avec les schémas.
Ce qui l'était moins, par contre, c'est que les constructeurs de machine ne protège pas leur design. Et c'est l'association des deux qui a permis l'essor du Compatible IBM PC.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: bios et succès du PC
Posté par eastwind☯ . Évalué à 5.
en fait j'ai un problème aussi avec le mot progéter utilisé dans le sens de la propriété intellectuelle.
J'ai l'impression que privatisé sonne plus juste
# table des partitions
Posté par Guillaume Knispel . Évalué à 5.
FOUTAISES.
Le bios n'a que faire de la table des partitions. Il ne connaît même pas son format.
[^] # Re: table des partitions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
À vrai dire, si, le BIOS sait lire les tables de partitions MS-DOS. Cela permet à un chargeur de démarrage de les utiliser sans pilote, sans pilote de table de partition j'entends, mais pas sans pilote de système de fichiers.
Ceci dit, cette possibilité est rarement utilisée de nos jours.
[^] # Re: table des partitions
Posté par Anthony Jaguenaud . Évalué à 5.
Non, le BIOS lit et exécute le mbr (1° secteur du disque) sur les 440 premiers octets (les suivants sont la table de partition) il charge le premier secteur de la partition active.
Grub, quand on l’installe sur une partition active cette partition et mets sont code dedans.
Lilo écrasé systématiquement le mbr (il y a longtemps que je ne l’utilise plus, il a peut-être évolué).
C’est le chargeur de démarrage qui interprète les partitions.
[^] # Re: table des partitions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Non plus.
Historiquement en effet, on utilisait une amorce placée en MBR, qui chargeait le code de la partition active, en utilisant pour cela les fonctionnalités du BIOS qui est capable de lire la table de partition MS-DOS.
Aujourd'hui plus personne ne procède ainsi. On place toujours une amorce en MBR mais celle-ci n'utilise plus les partitions, à la place elle charge le code présent à une adresse précise. Dans le cas de GRUB sur BIOS ou sur UEFI, le code en question est situé :
[^] # Re: table des partitions
Posté par Anthony Jaguenaud . Évalué à 2.
J’ai décris comment ça devrait ce passer. Par habitude, du fait que windows réinitialisait le mbr à l’installation, j’ai toujours installé grub sur la partition /boot (hd0,1) par exemple.
Ce que tu dis est vrai si on installe sur le mbr (hd0). Et là, oui, il utilise l’espace inter partition parce que les OS préfère avoir des frontières en cylindre, la table de partition supporterait très bien de commencer sur le cylindre 0, tête 0, secteur 2…
Je crois, que c’est surtout un choix des distributions de proposer par défaut le mbr pour installer grub.
Pendant longtemps, j’ai utilisé un CD win95 pour avoir un DOS et la commande fdisk /mbr pour le restaurer.
Aujourd’hui, il y a un package mbr dans les distributions permettant de le restaurer.
[^] # Re: table des partitions
Posté par NanoTech . Évalué à 5.
L'amorce placée sur le MBR "standard" (introduit avec MS-DOS 2.0), qui charge le Volume Boot Record de la partition active traite lui-même la table de partition, et non pas le BIOS. Par exemple, le MBR de MS-DOS 7.1, appelle INT 13H/AH=02h ou INT 13h/AH=42h, en fonction d'un flag à 0x0002.
La vieille API CHS du BIOS limitait les disques à 8.4 Go. La nouvelle API LBA/EDD, monte cette limite à 2^64 blocs, soit 8 Zebi-octets.
Le BIOS est agnostique du partitionnement. Si tu trouves une fonction du BIOS sur la RBIL qui ne le soit pas, peux-tu me la donner?
Références:
http://thestarman.pcministry.com/asm/mbr/MSWIN41.htm
http://www.ctyme.com/intr/rb-0607.htm
http://www.ctyme.com/intr/rb-0708.htm
[^] # Re: table des partitions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Ah, au temps pour moi, alors.
[^] # Re: table des partitions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Pas forcément, un chargeur de démarrage pourrait tout à fait utiliser l'ABI du BIOS pour cela. Mais plus personne ne procède ainsi actuellement, parce que ce ne serait pas portable.
[^] # Re: table des partitions
Posté par Guillaume Knispel . Évalué à 3.
http://www.ctyme.com/intr/int-13.htm <-- c'est quoi l'appel pour avoir des infos sur les partitions ? En outre même s'il en existait un, who cares ? ça n'empêche pas d'utiliser du GPT sur un PC avec un BIOS, ou même un truc plus exotique -- il suffit de ne pas s'en servir. Bref cet argument pour tenter de justifier EFI n'a pas de sens. De plus il suffirait de changer la manière dont un BIOS standard interprète la table de partition pour lui faire faire du GPT ou de créer une nouvelle fonction pour régler ce "problème" (éventuelle mettre du option pour choisir GPT / MSDOS si ya vraiment des bios qui se servent de la table de partition, mais sans référence concrète je continue à penser que ça n'existe pas ou au pire c'est extrêmement marginal)
Le pire c'est que cette désinformation transformée en argument pour dire qu'on a besoin d'EFI est propagée à l'origine par les promoteurs corpo d'EFI. Bref des gens qui recourent au FUD, comme à leur habitude.
# La spécification
Posté par Guillaume Knispel . Évalué à 10.
Non. C'est indigeste. Si vous mangez cette spécification vous allez vomir en while(true) jusqu'à vous déshydrater complètement pour finalement mourir. La spécification est remplie d'idées complètement crétines au delà de tout ce qui est imaginable (des headers PE qui ne servent à rien, un link dynamique ad-hoc codé naïvement C et qui utilise des GUID -- bref on sent la patte de MS à toutes les pages, et pas des meilleurs de chez MS...) et les implémentations sont encore pire que la spécification, les différents modules employant 42 méthodes différentes pour faire la même chose au grès de l'humeur du développeur (vive le bloat :/ ), et les vendeurs n'hésitant pas à patcher tianocore comme des gorets pour rajouter leur propre merde hookée n'importe comment à l'intérieur (qui fait d'ailleurs AUSSI exactement la même chose que les 42 merdes standardisés par la spécification). Pour vous donner un ordre d'idée de l'ampleur des dégats, je pensais fortement aux accès à l'espace de configuration PCI, qui nativement prennent deux instructions, et en passant pas les trucs standardisés d'EFI sont de mémoire 4× à 10× plus gros rien que l'appel de fonction qui bien sûr est un appel via GUID, et souvent à travers plusieurs couches de GUIDs. Bref, c'est du CACA. Évidemment la signature de ces fameuses fonctions sont stupides à souhait (c'est d'ailleurs en partie pour ça que ça prend autant de place dans le texte de l'appel).
Je n'en dirais pas plus pcq j'ai appris toussa en faisant des trucs pro vaguement borderline, mais si dans votre vie vous avez le choix entre éviter EFI et vous confronter à EFI, la dernière solution vous rendra heureux à jamais tandis que le choix 1. n'aboutira que sur de la tristesse et une raison supplémentaire de haïr un pan entier de l'espèce humaine.
En repensant à la patte de MS, je ne serais pas étonné si dans 5 à 10 ans cette boîte sympathique ne sorte pas des brevets idiots de son chapeau et extorque des paiements secrets à des "utilisateurs" de leur merveilleuse technologie, comme à son habitude. Encore une raison de fuir cette daube indigeste et nauséabonde comme la peste.
[^] # Re: La spécification
Posté par Guillaume Knispel . Évalué à 10.
Il y a une regrettable inversion qui c'est glissée dans mon commentaire précédent, trouvez l'erreur :)
[^] # Re: La spécification
Posté par xavier dumont . Évalué à 1.
choix 1 : trouvé
choix 2 : pas vu
J'ai fait le choix 2 !
PS : il y a une regrettable inversion dans mon post, trouvez laquelle.
[^] # Re: La spécification
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Il existe des versions de remplaçant de bios PC moins pourris ?
* genre un uboot comme dans l'embarqué ?
* voir plus compliqué, un linux réduit au minimum (8Mo ?) mais qui contient tous les éléments de la terre pour communiquer vers l'extérieur. Il faudrait peut-être définir une API pour lancer les OS externes.
"La première sécurité est la liberté"
[^] # Re: La spécification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu sais qu'en général, on demande plus au firmware que de simplement charger le système d'exploitation spécifique fourni par le fabricant ?
En vrac :
[^] # Re: La spécification
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
La configuration pourrait être simplement un ensemble clef-valeur écrit par un outil externe avec juste un moyen pour revenir au élément par défaut.
"La première sécurité est la liberté"
[^] # Re: La spécification
Posté par pralines . Évalué à 2.
coreboot (ex linux bios) non ?
pas beaucoup de cartes mètes desktop (57) supportées
mais je confond peut-être POST et BIOS...
Envoyé depuis mon Archlinux
[^] # Re: La spécification
Posté par mrjay42 (site web personnel) . Évalué à 5.
Ok, c'était un coup de gueule, qui semble valable et fondé...
Toutefois, en tant que "noob", j'aimerais avoir plus de détails : tu peux faire péter des liens vers les sources de ce que tu dis ? ou mettre des exemples...si ça te chante hein.
Mais ça aurait le mérite de donner du corps à ton propos qui se résume pour l'instant à un coup de gueule qui semble argumenté...
[^] # Re: La spécification
Posté par Guillaume Knispel . Évalué à 5.
Les sources sont la lecture de la spécification et de tianocore. Peux être que si j'ai du temps et que je m'ennuie beaucoup je pointerais vers des pages, des paragraphes précis dans la spec, ainsi que des fichiers et fonctions précise dans tianocore, et que j'en ferais une analyse détaillée pour expliquer pourquoi c'est du caca.
[^] # Re: La spécification
Posté par Guillaume Knispel . Évalué à 0.
Les sources sont la lecture de la spécification et de tianocore. Peux être que si j'ai du temps et que je m'ennuie beaucoup je pointerais vers des pages, des paragraphes précis dans la spec, ainsi que des fichiers et fonctions précise dans tianocore, et que j'en ferais une analyse détaillée pour expliquer pourquoi c'est du caca.
# Plug'n'Pray
Posté par Tuxologue . Évalué à -5.
C'est quoi ce gros troll ?
[^] # Re: Plug'n'Pray
Posté par Pinaraf . Évalué à 7.
T'as jamais eu de conflits avec le plug and play ?
Perso je considère qu'il faut prier pour que ça marche dans tous les cas, parce que quand ça foire, c'est devenu très difficile à corriger.
[^] # Re: Plug'n'Pray
Posté par Low Memory . Évalué à 0.
Peut-être qu'il y a un lien avec le film (en) ?
# DOS gravé dans le marbre
Posté par NanoTech . Évalué à 10.
Ce qui est super avec la spécification EFI, c'est qu'elle ne s'arrête pas à la gestion de la configuration matérielle, mais elle s'étend à des choses purement logicielles comme le boot loader.
Plutôt que d'utiliser un BOOT loader débuggé et universel comme GRUB, pourquoi ne pas faire une spécification et une implémentation différente sur chaque BIOS, avec bien sûr, bon nombre de bogues jamais corrigés, comme ça tout le monde va pouvoir en baver?
La leçon que j'ai tirée de mon expérience avec les BIOS c'est que l'on devrait réduire ça au strict minimum vital
Mon rêve:
BIOS réduit a des simples tables descriptives (p.e. pour le routing des IRQ) + un boot-loader ultra-minimaliste juste capable de charger une flash contenant un OpenBIOS indépendant de la machine ou, si une touche magique ou cavalier est activé, démarrer un OpenBIOS de référence depuis une ROM, pour éviter que l'on ne brique la machine.
Matthew Garrett (développeur du noyau Linux pour Red Hat), a très bien expliqué ce qu'est EFI en quelques mots:>
> UEFI stands for “Unified Extensible Firmware Interface”, where “Firmware”
> is an ancient African word meaning “Why do something right when you can
> do it so wrong that children will weep and brave adults will cower before you”,
> and “UEI” is Celtic for “We missed DOS so we burned it into your ROMs”.
–Matthew Garrett
# temps de démarrage
Posté par contre_maitre . Évalué à 1.
Ce n'est pas dis dans l'article, mais il me semble que l'UEFI devrait permettre des temps de démarrage (entre la mise sous tension et le début du chargement de l'OS) beaucoup plus court que le bios.
[^] # Re: temps de démarrage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça c'est du bullshit marketing. Si les BIOS sont lents c'est plutôt parce qu'ils sont codés avec les pieds, j'ai l'impression.
[^] # Re: temps de démarrage
Posté par NanoTech . Évalué à 3.
Le "temps" de démarrage du BIOS, c'est uniquement le temps du POST (Power-On Self Test), qui est très très variable en durée.
J'ai vu des machines pour lesquelles c'était une ou deux secondes, et d'autres où c'est 30 secondes.
Après, une fois que ça a chargé le MBR, le temps de chargement du bootloader dépend un peu de la qualité d'implémentation de la fonction de lecture de disque INT 13h/AH=42h, mais, changer l'interface ne va pas améliorer les performances, parce qu'elle est déjà bien conçue (possibilité de lire plusieurs blocs contigus en un seul appel). De toute façon, ça nécessite souvent moins d'une seconde.
Quand au "secure boot", c'est aussi du BS marketing. Prèsque aucun malware ne modifie le fichier de démarrage de l'OS. L'objectif est uniquement de rendre plus difficile l'ajout de pilotes non signés pour les gens qui veulent contourner les DRM.
[^] # Re: temps de démarrage
Posté par Pinaraf . Évalué à 3.
Là par contre secure boot me semble répondre à un vrai problème, en tout cas sur la plateforme windows : comment lutter contre un rootkit qui va s'insérer au niveau du noyau, via un pilote ? (Réponse : en obligeant la signature du pilote... mais justement, pour contourner cette obligation de signature, les rootkit peuvent s'insérer "sous" le noyau via les technos de virtualisation par exemple)
Après, on peut douter de l'efficacité de la protection quand on voit que des rootkits ont été diffusés avec un pilote signé... Hé oui, les failles des autorités de confiance SSL, c'est mignon... mais on a le même genre de faille dans toute chaîne de confiance, et quand un constructeur de matériel (c'était realtek) se fait compromettre sa clé... Toute la sécurité du système s'en trouve compromise finalement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.