Get best of the week

Problèmes et fonctionnalités de l'implémentation UEFI sur diverses plates-formes

Environ dix-neuf ans se sont écoulés depuis la publication de la première spécification EFI en 2000. Il a fallu dix ans à l'interface pour pénétrer le marché des utilisateurs et y prendre pied. Pour le moment, vous pouvez rarement voir un ordinateur moderne sans UEFI dans le firmware de la carte mère. L'interface standard a augmenté la "viande" et plusieurs milliers de pages dans la documentation officielle. Pour l'utilisateur moyen, rien n'a changé, à l'exception des collisions occasionnelles avec Secure Boot activé. Mais si le plan de travail passe au développement, tout devient plus intéressant.



Le concept même de l'architecture modulaire de l'UEFI implique que ces modules peuvent non seulement être utilisés dans la configuration standard, mais également télécharger quelque chose qui leur est propre. Le pilote du système de fichiers (non limité au FAT natif eFi-timide?), Les pilotes de périphériques, les applications, les chargeurs de démarrage - vous pouvez tout charger à la main, il serait bien de charger un peu de Shell. Vous pouvez aller plus loin et regarder le contenu du firmware, vous évitant de danser avec SecureBoot et la nécessité d'écrire une couche de scripts (il y a suffisamment d'articles sur les pages du hub).

Sur cette base, l'idée est née de créer des modules fonctionnels qui exécutent diverses fonctions de sécurité avant de charger le système d'exploitation, qui peuvent encore s'unir et devenir une sorte d'environnement de démarrage sécurisé intégré affectant à la fois les services de l'interface de démarrage et d'exécution de sorte qu'entre les modules du micrologiciel et les modules du disque rien ne pouvait être «poussé» sans intervention de bas niveau, et après eux - uniquement avec la permission de l'administrateur de la sécurité.

La mise en œuvre de cette idée nous a présenté un grand nombre de nuances et de subtilités de l'UEFI - à commencer par de nombreuses fonctionnalités, bogues et documents non documentés ou mal documentés, et se terminant par le comportement non défini tant apprécié par tous les développeurs. Commençons dans l'ordre.

Dépendance à la plateforme




La première chose que vous devez savoir lors de l'intégration à la plate-forme est de savoir si nous pouvons travailler avec elle? La version de la spécification UEFI est importante et, sur la plupart des appareils, elle est présentée dans une plage comprise entre 2,1 et 2,7. Le plus récent n'a pas encore atteint le stand de recherche. Le plus ancien est trouvé, et ses performances peuvent être limitées en raison de l'absence des protocoles nécessaires ou des pilotes écrits de manière tordue pour leur implémentation. Par exemple, UnicodeCollation n'est souvent pas suffisant, lors de l'accès aux smbios il y a des erreurs non documentées, les fonctions de changement de langue via SetVariable () ne fonctionnent pas. Tout peut arriver, selon le fournisseur et la fraîcheur, car il faut parfois mettre ses protocoles même sur des cartes relativement récentes.

Même dans notre pratique, j'ai eu la chance de tomber sur deux mini-ordinateurs avec Intel Bay Trail D et un firmware 32 bits à bord. Le cas est rare, mais à un moment donné, il a fallu recompiler d'urgence les modules. En fait, comme la question: allons-nous rencontrer à l'avenir une plate-forme plus moderne de la même capacité? Et si nous nous rencontrons, alors où?

L'étape suivante consiste à déterminer comment intégrer. Les modules sont intégrés au micrologiciel, le micrologiciel se trouve dans la puce SPI de la carte et PCH avec Intel ME est situé à proximité. Et ici se pose la question la plus intéressante - comment s'y rendre? Bon vieux programmeur avec un "crocodile" - c'est bien, c'est fiable. Même si vous ne vous attardez pas à la fin, vous pouvez toujours regarder les LED brûlantes sur la carte, elles ont suffisamment de puissance du programmeur. Il fonctionne presque parfaitement, à l'exception de certains anciens modèles HP, où le mikruha SOIC-16 avec firmware est si accessible qu'il est plus facile de concevoir et de souder l'adaptateur à ses jambes que de serrer le clip.



Je sais qu'il y a des gens sur Habré qui ont contribué à l'écriture de flashrom, grâce à eux séparément.

Mais, malgré la fiabilité et la fiabilité de la suppression des vidages par le programmeur, cette méthode ne convient pas si vous devez installer quelque chose dans UEFI sur plusieurs machines, ou si la plate-forme cible pour l'installation n'est pas sur votre bureau. Heureusement pour nous, les fabricants ont laissé derrière eux les utilitaires de firmware natifs: FPT (outil de programmation Flash) du kit Intel (CS) ME System Tools et AFU (AMI Firmware Update) pour Aptio d'American Megatrends. Ces utilitaires sont lancés à partir de l'environnement EFI et des systèmes d'exploitation Windows, Linux et DOS. Les utilitaires sont quelque peu interchangeables, les deux vous permettent de considérer l'image, sinon la totalité, puis certaines régions à coup sûr. Et parfois, ils vous laissent même réécrire.



Il écrit et n'écrit pas

C'est là que la première pierre d'achoppement sérieuse sur le chemin de l'intégration apparaît. Toutes les cartes mères ne vous permettent pas de lire l'intégralité du firmware, interdisant l'accès à la région ME (ME est presque sacré, Intel ne permettra pas qu'il soit lu dans le bon sens, mais dans le mauvais sens, nous ne voulons pas toujours). Encore moins - versez quelque chose même dans la région du BIOS, sauf s'il s'agit d'une capsule signée. Les chances de succès varient considérablement selon le fabricant et la fraîcheur du chipset. Sur certains modèles de cartes mères, vous pouvez observer une image amusante: celle qui n'était pas enregistrée sur les anciennes cartes des fournisseurs vole à de nouveaux moments.

Parfois, l' analyseur IFR aide à lutter contre la protection en écriture, ce qui ouvre le rideau sur les paramètres et les variables cachés. Et parfois, seul un cavalier hardcore aide, permettant d'accéder à l'enregistrement ou de "désactiver" ME (si un est fourni, bien sûr).

La nature complexe des systèmes


Dans la plupart des cas, les cartes Acer, Asus, AsRock et Gigabyte sont écrites sans difficultés inutiles. Intel, HP et le matériel serveur se distinguent. Non seulement HP n'autorise pas l'écriture par programmation, mais il jure également à toute tentative de modification du micrologiciel (dansCodeRush il existe des articles sur la recherche et la désactivation de la vérification d'intégrité). Intel a plus ou moins enregistré jusqu'au 87ème chipset, puis il est devenu sourd aux demandes d'ouverture des portes de la région BIOS.

Avec Intel, la première fois était drôle. Les modules ont été importés dans le firmware à l'aide de l'utilitaire UEFITool, et nous sommes tombés sur un bug intéressant: si nous insérons des modules ffs à la fin du volume DXE, après toutes les formes libres, l'image assemblée «maquillait» la carte. La solution était d'ajouter des modules après n'importe quel pilote DXE natif. Nous n'y sommes pas immédiatement arrivés, et au début, il semblait qu'Intel surveillait l'intégrité du firmware, comme HP. Plus tard, il est devenu clair que l'on ne pouvait pas se passer d'un utilitaire automatique pour importer des modules, et le problème est venu à néant après l'avoir écrit.

Le matériel côté serveur est à la fois plus simple et plus complexe. D'une part, il existe toujours des moyens supplémentaires de mettre à jour et de modifier les BIOS sur les serveurs, d'autre part, le volume de personnalisation dans ces mêmes BIOS est écrasant, car ils ne lésinent pas sur les serveurs et n'installent pas de puces de mémoire flash assez volumineuses, souvent également en les sauvegardant.

Lors de l'installation sur un serveur, il est toujours agréable de pouvoir mettre à jour le BIOS à distance via IPMI. Certes, pour cela, vous avez besoin d'une licence, bien sûr payée. S'il n'apparaît pas au bon moment, il est tout à fait possible de se retrouver dans une situation amusante, similaire à celle que nous avons eue en introduisant des modules dans le BIOS du serveur Supermicro.

Après l'introduction des modules, la charge se bloque fortement en raison du blocage par l'un des modules de sécurité (ils n'ont pas pris en compte le caractère capricieux des BIOS du serveur, avec qui cela n'arrive pas!). En l'absence de la possibilité de forcer le BIOS à être restauré via IPMI, la main elle-même a atteint le programmeur, mais ce n'était pas une chance - le clip SOIC-8 standard n'était pas suffisant pour une puce SOIC-16! Eh bien, d'accord, car en théorie, la carte serveur a la possibilité de sauvegarder à partir du support connecté, en récupérant l'image SUPER.ROM à la racine. Mais ce mécanisme ne démarre pas, car selon le système tout va bien, tout fonctionne, donc, la restauration du BIOS n'est pas nécessaire! Que faire?! .. L'histoire a fini par courir dans la ville à la recherche du bon clip, un resoudage d'urgence des fils, enduit par les Chinois dans un ordre incompréhensible pour nous, et enfin - un clignotement.

Lenovo est sorti encore plus intéressant. Sur les commutateurs reçus du vendeur, sous le couvercle du boîtier, une carte de contrôle a été trouvée avec deux "mikruhs" pour firmware, avec un SSD pour OS et avec une batterie fixe. Le BIOS s'est avéré être un dur à cuire, je ne voulais en aucun cas manger une image modifiée, ne succombant qu'au programmeur. Dans l'une des tentatives d'écrire quelque chose, ils ont inséré un lecteur flash avec la console ubuntu dans le commutateur (le terminal n'a pas donné de graphiques) et ont démarré en toute sécurité. Après avoir fait ce qui était nécessaire, ils ont éteint le système en utilisant la commande halt -p de l'ancienne mémoire. L'interrupteur, de par sa nature, n'était adapté à aucun arrêt, sauf par manque de puissance, n'était pas prêt pour cela et ne voulait plus démarrer. Le lien sur le visage a brûlé une fois, les fans ont bruissé doucement et tous les ports n'ont rien révélé. Le nouveau clignotement n'a pas aidé,la batterie était assise comme un gant - nous avions peur de casser la monture. En conséquence, une fine plaque diélectrique a rampé sous la force de la persévérance et de l'inspiration verbale sous les contacts, la mémoire volatile a été effacée, l'interrupteur a pris vie.

L'étude des décharges prélevées sur deux puces a montré beaucoup de choses intéressantes. En particulier, un grand nombre d'entrées "invalides" dans la NVRAM du firmware principal et plusieurs similaires dans la sauvegarde. Eh bien, et pas un hachage de données rencontré précédemment dans le volume avec les pilotes DXE. On ne pouvait que deviner la cause exacte du problème de démarrage du commutateur.

En général, la partie logicielle est rarement privée de ses nuances inattendues. De nombreuses cartes mères que nous avons rencontrées jusqu'au 87e chipset (de différents fabricants) ont la caractéristique désagréable de générer un flux infini d'erreurs lors de la saisie de la commande "dh -v" dans la console shell. Avec la saisie manuelle, ce n'est pas critique, mais lors de la collecte de données dans un fichier, cela se termine par un blocage malheureux. Dans les deux cas, vous devez redémarrer la machine. Je suis heureux qu'en même temps le fichier de données ne gonfle pas à des tailles immenses.



Le BIOS Kraftway avec carte ASRock H81M-DGS s'est révélé très capricieux. Ainsi, il répond à Ctrl Alt Del Del par un accrochage, duquel seul Reset peut le sortir. Il y a eu des problèmes pour ignorer le script de démarrage <startup.nsh> dans Shell'e - une fraction de seconde à choisir au lieu de cinq par défaut. Peut-être que ces problèmes sont causés par la modification par les modules propriétaires de KSS, peut-être que le problème est inexactement «dévissé» ME.

Sur la carte Asus H97-PLUS, le firmware a la fonctionnalité suivante - BootOrder déborde au fil du temps. Très probablement, la raison réside dans les erreurs dans le code. Bien que, peut-être, le fabricant ait voulu conserver tous les périphériques de démarrage jamais connectés à la carte, mais n'a pas calculé qu'il pourrait y en avoir plus d'une douzaine en une journée. Ainsi, lorsque BootOrder déborde, le système se bloque pendant le processus de démarrage. Pour le nettoyer, vous devez éteindre tous les périphériques de démarrage et allumer le système. Le firmware s’efface et le système démarre directement dans le shell de configuration du BIOS. Les performances restent jusqu'au prochain débordement.

En résumant l'expérience de travail avec les conseils d'administration de divers fournisseurs, vous arrivez à la conclusion qu'il est presque impossible de savoir quelles surprises au niveau EFI vous aurez à traiter sur le prochain tableau, même s'il a déjà un modèle bien connu. Il s'agit d'une sorte de loterie, car des difficultés peuvent parfois survenir au stade de la collecte d'informations sur le système. Peut-être cela a-t-il une part d'idéalisme de recherche inextinguible et de confiance dans le fabricant, car comment autrement certaines des cartes mères les plus récentes avec ME v11 et v12 pourraient-elles se bloquer lors de l'exécution de FPT ou MEInfo des anciennes versions?

Problèmes de travail avec les protocoles matériels




Certains problèmes apparaissent lorsque nous commençons à travailler avec des périphériques USB - lecteurs et jetons. Cela se produit souvent parce que le code BIOS pour travailler avec les périphériques est un dangereux cocktail de pilotes et d'applications du fournisseur de matériel indépendant (IHV) pour un périphérique spécifique, du code du fabricant du chipset (dans notre cas, d'Intel), du code du fabricant du BIOS et du code du fabricant de la carte mère.

Les situations «intéressantes» suivantes se

sont produites : jeton «non détecté». En même temps, une LED est allumée dessus. Très probablement, le contrôleur hôte ne passe pas par la procédure de réinitialisation initiale du périphérique USB, c'est-à-dire que l'alimentation est fournie, mais la réinitialisation en modifiant les lignes D + et D- ne fonctionne pas correctement, et sans cela, aucune autre manipulation avec le jeton n'a de sens.

L'ordinateur se fige avant de charger le shell (encore une fois, avec un jeton connecté). Dans ce cas, sans jeton, le PC démarre normalement. En direct, cela ressemble à ceci: l'ordinateur semble planter juste après le démarrage, tandis que le jeton sort du connecteur. Vous le retirez - le chargement continue soudainement. Connectez-vous - suspendu à nouveau. Le problème évident est dans UEFI, et on ne peut que spéculer sur les raisons.

La situation où il n'est pas possible d'ouvrir l'interface USB_IO. Peut-être qu'il est connecté uniquement avec l'interface pour travailler avec des cartes à puce - USB CCID. Un pilote AMI a déjà ouvert USB_IO avec le paramètre EFI_OPEN_PROTOCOL_BY_DRIVER. Le pilote a un protocole avec un GUID:

#define EFI_AMI_USB_CCID_PROTOCOL_GUID	 { 0x5FDEE00D, 0xDA40, 0x405A, { 0xB9, 0x2E, 0xCF, 0x4A, 0x80, 0xEA, 0x8F, 0x76} }
 // Workaround.      EFI_OPEN_PROTOCOL_BY_DRIVER,  ,     EFI_OPEN_PROTOCOL_GET_PROTOCOL.
 //
 // Open USB I/O Protocol
 //
 Status = gBS->OpenProtocol (
 ControllerHandle,
 &gEfiUsbIoProtocolGuid,
 (VOID **) &UsbIo,
 This->DriverBindingHandle,
 ControllerHandle,
 EFI_OPEN_PROTOCOL_BY_DRIVER
 );

 if (EFI_ACCESS_DENIED == Status)
 {		// AMI BIOS workaround (BindingStop will not be invoked)
	 Status = gBS->OpenProtocol(
		 ControllerHandle,
		 &gEfiUsbIoProtocolGuid,
		 (VOID **)&UsbIo,
		 This->DriverBindingHandle,
		 ControllerHandle,
		 EFI_OPEN_PROTOCOL_GET_PROTOCOL
	 );
 }

Cependant, BindingStop () ne sera pas appelé, c'est-à-dire l'événement d'extraction de périphérique n'est pas surveillé et le pilote essaiera d'utiliser un handle non valide. Cela a été observé avec le PC HP Compaq Elite 8300 SFF et quelques autres. Il s'agit soit d'une sorte de protection des fournisseurs contre les pilotes indésirables, soit d'un bogue de développement normal. Peut-être qu'AMI fait constamment quelque chose en direction de USB CCID, mais le pilote interférant ne peut pas être déchargé, car il est situé dans le même module AMI UHCI avec USB HID, USB MassStorage. Avec UninstallInterface (), les choses sont similaires.

Ou une autre fonctionnalité intéressante. Dans l'un des BIOS UEFI, où le jeton n'a pas été détecté, USB_IO a autorisé la lecture des descripteurs de périphérique, mais EFI_INVALID_PARAMETER est revenu au prochain UsbBulkTransfer (). De plus, cela ne s'est produit qu'avec certains types de jetons, avec absolument les mêmes paramètres, d'autres fonctionnaient parfaitement.

En général, dans le protocole EFI_USB_IO_PROTOCOL, la méthode UsbBulkTransfer () est implémentée de manière intéressante. Il est prévu pour une livraison de colis garantie pour une durée illimitée ou pour la durée spécifiée dans le paramètre Timeout. Mais une expérience a été menée avec un appareil MassStorage: lors de la copie d'un gros fichier sur une clé USB, il a été supprimé. Le PC se bloque fermement. Lors de la connexion de la clé USB, le PC s'est affaissé et a continué à écrire le fichier comme si de rien n'était. La même situation était avec des jetons, mais avec ses propres spécificités. C'est un problème architectural, dans EFI il n'y a pas d'interruptions sauf une minuterie, et les appareils fonctionnent selon un sondage. Autrement dit, le système s'est écrasé quelque part dans le sondage USB, mais n'a pas atteint la sortie de délai d'expiration; lorsque l'appareil réapparaît, il a simplement continué et terminé l'opération.

Virtualisation


Nous devrions également parler des environnements virtuels. Actuellement, il existe deux principales plates-formes sur le marché qui prennent en charge l'émulation de l'environnement EFI: VMware et VirtualBox. Les deux ont leurs avantages et leurs inconvénients lorsqu'ils interagissent avec eux comme avec les «vrais» systèmes. L'environnement VMware fournit un travail adéquat avec les variables NVRAM, mais trébuche lors de l'affichage visuel des messages lors de l'initialisation des modules DXE: dans le meilleur des cas, la préférence sera donnée aux messages natifs sur la recherche de supports de démarrage, laissant derrière nous ce dont nous avons besoin. VirtualBox, au contraire, rend parfaitement tout ce qui est nécessaire, mais ne veut pas se souvenir de longues variables.

Une autre petite pierre dans le jardin VMware - le pilote FAT32 intégré prend en charge la création et l'édition de fichiers uniquement en notation 8.3. Il n'est pas clair pourquoi cela a été fait, mais c'est une limitation qui nécessite clairement une attention. Il est probable qu'une implémentation similaire du pilote puisse être observée sur des plates-formes réelles, mais jusqu'à présent, nous ne les avons pas rencontrées.

D'autre part, dans les machines virtuelles, il n'y a pas de danses avec des utilitaires de firmware, des programmeurs, des cavaliers, des puces inconfortables. Un fichier ROM séparé, UEFITool et une ligne dans le fichier de configuration. Presque une idylle.

À la fin



Une tranche de la demande de CHIPSEC. Où enseignent-ils de tels sacrements?

Comme déjà mentionné, le développement et la mise en œuvre dans le shell UEFI est un processus fascinant et créatif. Vous pouvez toujours trouver quelque chose de nouveau, même sur un domaine célèbre. D'une part, il est encourageant de constater que la norme évolue, d'autre part, il est triste que les mises en œuvre concrètes de celle-ci par les producteurs soient trop «créatives».

Les principaux problèmes étaient et demeurent:

  1. Départ des fournisseurs de la spécification UEFI lors du développement du firmware.
  2. Erreurs dans le code lors de l'implémentation.
  3. NDV dans le code, pop-up lors de l'intégration.

Et enfin, mais non des moindres, l'absence de beaucoup de choses dans la documentation officielle (lue, ouverte), comme, par exemple, les descriptions du protocole pour communiquer avec ME via des périphériques PCI comme MEI, HECI. Vous pouvez trouver une description des registres, mais pas les commandes. Trouvez un GUID, mais pas son objectif. Ce qui renvoie encore une fois le travail à une longue analyse, collecte de données et statistiques sur les plateformes et utilisation du démonteur.

Il convient de noter que la situation se corrige lentement mais sûrement, et je veux croire que le moment n'est pas loin où l'élaboration de la norme deviendra un processus assez prévisible et très agréable.

Vladimir Onipchuk,
responsable du groupe de produits de protection matérielle et logicielle de
Gazinformservice LLC

More articles:


All Articles