Get best of the week

Probleme und Funktionen der UEFI-Implementierung auf verschiedenen Plattformen

Seit der Veröffentlichung der ersten EFI-Spezifikation im Jahr 2000 sind etwa neunzehn Jahre vergangen. Es dauerte zehn Jahre, bis die Benutzeroberfläche in den Benutzermarkt eingetreten war und dort Fuß gefasst hatte. Im Moment kann man selten einen modernen Computer ohne UEFI in der Firmware des Motherboards sehen. Der Schnittstellenstandard hat das "Fleisch" und mehrere tausend Seiten in der offiziellen Dokumentation erhöht. Für den durchschnittlichen Benutzer hat sich nichts geändert, außer gelegentlichen Kollisionen mit aktiviertem Secure Boot. Wenn sich die Arbeitsebene jedoch zur Entwicklung verschiebt, wird alles interessanter.



Das Konzept der modularen Architektur von UEFI impliziert, dass diese Module nicht nur in der Standardkonfiguration verwendet werden können, sondern auch etwas Eigenes herunterladen können. Der Dateisystemtreiber (nicht beschränkt auf das native eFi-schüchterne FAT?), Peripherietreiber, Anwendungen, Bootloader - Sie können alles von Hand laden, es wäre schön, ein bisschen Shell zu laden. Sie können einen Schritt "tiefer" gehen und sich den Inhalt der Firmware ansehen, um sich vor dem Tanzen mit SecureBoot und der Notwendigkeit zu schützen, eine Schicht von Skripten zu schreiben (es gibt genügend Artikel auf den Seiten des Hubs).

Auf dieser Grundlage entstand die Idee, vor dem Laden des Betriebssystems Funktionsmodule zu erstellen, die verschiedene Sicherheitsfunktionen ausführen. Diese können sich weiter vereinen und zu einer Art integrierter vertrauenswürdiger Startumgebung werden, die sich sowohl auf die Dienste der Start- als auch auf die Laufzeitschnittstelle auswirkt, sodass zwischen den Modulen in der Firmware und den Modulen auf der Festplatte Nichts konnte ohne Eingreifen auf niedriger Ebene und danach "gepusht" werden - nur mit Erlaubnis des Sicherheitsadministrators.

Die Umsetzung dieser Idee führte uns in eine Vielzahl von Nuancen und Feinheiten von UEFI ein - angefangen bei vielen undokumentierten oder schlecht dokumentierten Funktionen, Fehlern bis hin zu dem undefinierten Verhalten, das von allen Entwicklern so geliebt wird. Fangen wir in der richtigen Reihenfolge an.

Plattformabhängigkeit




Das erste, was Sie bei der Integration in die Plattform herausfinden müssen, ist, ob wir damit arbeiten können. Die Version der UEFI-Spezifikation ist wichtig und wird auf den meisten Geräten im Bereich zwischen 2.1 und 2.7 angeboten. Der neuere hat den Forschungsstand noch nicht erreicht. Das ältere wird gefunden, und seine Leistung kann aufgrund des Fehlens der erforderlichen Protokolle oder schief geschriebenen Treiber für deren Implementierung eingeschränkt sein. Beispielsweise reicht UnicodeCollation häufig nicht aus. Wenn auf smbios zugegriffen wird, treten undokumentierte Fehler auf. Die Sprachänderungsfunktionen über SetVariable () funktionieren nicht. Je nach Anbieter und Aktualität kann alles passieren, da Sie Ihre Protokolle manchmal sogar auf relativ neuen Boards ablegen müssen.

Selbst in unserer Praxis hatte ich das Glück, auf zwei Mini-Computer mit Intel Bay Trail D und 32-Bit-Firmware an Bord zu stoßen. Der Fall ist selten, machte es jedoch einmal erforderlich, die Module dringend neu zu kompilieren. Eigentlich wie die Frage: Werden wir in Zukunft auf eine modernere Plattform mit der gleichen Kapazität treffen? Und wenn wir uns treffen, wo dann?

Der nächste Schritt besteht darin, zu bestimmen, wie integriert werden soll. Die Module sind in die Firmware integriert, die Firmware befindet sich im SPI-Chip auf der Platine und PCH mit Intel ME befindet sich in der Nähe. Und hier stellt sich die interessanteste Frage: Wie kommt man dorthin? Guter alter Programmierer mit einem "Krokodil" - das ist gut, es ist zuverlässig. Auch wenn Sie nicht bis zum Ende durchhalten, können Sie immer auf die brennenden LEDs auf der Platine schauen, sie haben genug Strom vom Programmierer. Es funktioniert fast einwandfrei, mit Ausnahme einiger älterer HP-Modelle, bei denen mikruha SOIC-16 mit Firmware so zugänglich ist, dass es einfacher ist, den Adapter zu konstruieren und an ihre Beine zu löten, als den Clip zusammenzudrücken.



Ich weiß, dass es auf Habré Leute gibt, die dank ihnen separat zum Schreiben von Flashrom beigetragen haben.

Trotz der Zuverlässigkeit und Zuverlässigkeit der Speicherauszugsentfernung durch den Programmierer ist diese Methode nicht geeignet, wenn Sie etwas in UEFI auf mehreren Computern installieren müssen oder wenn sich die Zielplattform für die Installation nicht auf Ihrem Schreibtisch befindet. Zum Glück haben die Hersteller native Firmware-Dienstprogramme zurückgelassen: FPT (Flash-Programmiertool) von Intel (CS) ME System Tools und AFU (AMI Firmware Update) für Aptio von American Megatrends. Diese Dienstprogramme werden sowohl von der EFI-Umgebung als auch von den Betriebssystemen Windows, Linux und DOS gestartet. Die Dienstprogramme sind etwas austauschbar. Mit beiden können Sie das Bild, wenn nicht das Ganze, bestimmte Regionen mit Sicherheit betrachten. Und manchmal lassen sie dich sogar zurückschreiben.



Er schreibt und schreibt nicht

Hier erscheint der erste ernsthafte Stolperstein auf dem Weg der Integration. Nicht auf allen Motherboards können Sie die gesamte Firmware lesen und den Zugriff auf die ME-Region verbieten (ME ist fast heilig, Intel lässt es nicht zu, dass es gut gelesen wird, aber auf schlechte Weise wollen wir es nicht immer). Noch weniger - gießen Sie etwas sogar in die BIOS-Region, es sei denn, es handelt sich um eine signierte Kapsel. Die Erfolgswahrscheinlichkeit variiert stark je nach Hersteller und Frische des Chipsatzes. Bei einigen Motherboard-Modellen ist ein lustiges Bild zu sehen: Das, was nicht auf den alten Vendor-Boards aufgezeichnet wurde, fliegt zu neuen Zeiten.

Manchmal hilft der IFR-Parser dabei , den Schreibschutz zu bekämpfen, was den Vorhang für versteckte Einstellungen und Variablen öffnet. Und manchmal hilft nur ein Hardcore-Jumper, der den Zugriff auf die Aufnahme ermöglicht oder ME "ausschaltet" (falls vorhanden).

Die Komplexität von Systemen


Die Acer-, Asus-, AsRock- und Gigabyte-Karten werden in den meisten Fällen ohne unnötige Schwierigkeiten geschrieben. Intel-, HP- und Serverhardware zeichnen sich aus. HP erlaubt nicht nur nicht, programmgesteuert in sich selbst zu schreiben, sondern schwört auch bei jedem Versuch, die Firmware zu ändern (inCodeRush Es gibt Artikel zum Auffinden und Deaktivieren der Integritätsprüfung. Intel hat mehr oder weniger bis zum 87. Chipsatz aufgenommen, dann wurde es taub für Anfragen, die Tore der BIOS-Region zu öffnen.

Mit Intel war das erste Mal lustig. Die Module wurden mit dem Dienstprogramm UEFITool in die Firmware importiert, und wir stießen auf einen interessanten Fehler: Wenn Sie am Ende des DXE-Volumes nach allen Freiforms ffs-Module einfügen, hat das zusammengesetzte Image die Platine „gemauert“. Die Lösung bestand darin, Module nach jedem nativen DXE-Treiber hinzuzufügen. Wir sind nicht sofort dazu gekommen, und auf den ersten Blick sah es so aus, als würde Intel die Integrität der Firmware überwachen, wie HP. Später wurde klar, dass man auf ein automatisches Dienstprogramm zum Importieren von Modulen nicht verzichten konnte, und das Problem wurde nach dem Schreiben zunichte gemacht.

Serverseitige Hardware ist gleichzeitig einfacher und komplexer. Einerseits gibt es immer zusätzliche Möglichkeiten, BIOSs auf Servern zu aktualisieren und zu ändern, andererseits ist das Anpassungsvolumen in denselben BIOSs überwältigend, da sie nicht an Servern sparen und recht umfangreiche Flash-Speicherchips installieren und diese häufig auch sichern.

Bei der Installation auf einem Server ist es immer schön, das BIOS über IPMI remote aktualisieren zu können. Richtig, dafür braucht man natürlich eine Lizenz, die natürlich bezahlt wird. Wenn es nicht zum richtigen Zeitpunkt erscheint, ist es durchaus möglich, in eine lustige Situation zu geraten, ähnlich der, die wir durch die Einführung von Modulen in das Supermicro-Server-BIOS erhalten haben.

Nach der Einführung der Module friert die Last aufgrund der Blockierung durch eines der Sicherheitsmodule stark ein (sie berücksichtigten nicht die Unberechenbarkeit der Server-BIOSs, mit denen dies nicht geschieht!). Da das BIOS nicht über IPMI zurückgesetzt werden konnte, griff die Hand selbst nach dem Programmierer, aber es war ein Pech - der Standard-SOIC-8-Clip reichte für einen SOIC-16-Chip nicht aus! Okay, denn theoretisch kann die Serverplatine von den angeschlossenen Medien sichern und das SUPER.ROM-Image im Stammverzeichnis aufnehmen. Dieser Mechanismus startet jedoch nicht, da laut System alles in Ordnung ist, alles funktioniert und daher kein BIOS-Rollback erforderlich ist! Was tun?! .. Die Geschichte lief durch die Stadt auf der Suche nach dem richtigen Clip, einem Notlöten von Drähten, das von den Chinesen in einer für uns unverständlichen Reihenfolge verschmiert wurde, und schließlich - einem Blinken.

Lenovo kam noch interessanter heraus. Auf den vom Hersteller erhaltenen Schaltern wurde unter dem Deckmantel des Gehäuses eine Steuerplatine mit zwei „Mikruhs“ für Firmware, einer SSD für Betriebssysteme und einem festen Akku gefunden. Das BIOS stellte sich als harte Nuss heraus. Ich wollte in keiner Weise ein modifiziertes Image essen, sondern nur dem Programmierer erliegen. Bei einem der Versuche, etwas aufzuschreiben, steckten sie ein Flash-Laufwerk mit Konsolen-Ubuntu in den Switch (das Terminal gab keine Grafiken aus) und starteten ziemlich sicher. Nachdem sie das Notwendige getan hatten, schalteten sie das System mit dem Befehl halt -p aus dem alten Speicher aus. Der Schalter war von Natur aus nicht für ein Herunterfahren geeignet, außer für den Mangel an Strom, war dafür nicht bereit und wollte nicht mehr starten. Die Verbindung im Gesicht brannte einmal durch, die Ventilatoren raschelten leise und alle Anschlüsse gaben nichts heraus. Ein erneutes Blinken hat nicht geholfen,Die Batterie saß wie angegossen - wir hatten Angst, die Halterung zu zerbrechen. Infolgedessen kroch eine dünne dielektrische Platte unter der Kraft der Beharrlichkeit und der verbalen Inspiration unter den Kontakten, der flüchtige Speicher wurde gelöscht, der Schalter wurde lebendig.

Die Untersuchung von Deponien aus zwei Chips zeigte viele interessante Dinge. Insbesondere eine große Anzahl von "ungültigen" Einträgen im NVRAM der Hauptfirmware und mehrere ähnliche im Backup. Nun, und kein zuvor angetroffener Daten-Hash im Volume mit DXE-Treibern. Man konnte nur die genaue Ursache des Problems beim Starten des Schalters erraten.

Im Allgemeinen wird der Softwareteil selten seiner unerwarteten Nuancen beraubt. Viele Motherboards, die vor dem 87. Chipsatz (von verschiedenen Herstellern) zu uns kamen, haben eine unangenehme Funktion, die bei der Eingabe des Befehls "dh -v" in der Shell-Konsole einen endlosen Strom von Fehlern erzeugt. Bei der manuellen Eingabe ist dies nicht kritisch, aber beim Sammeln von Daten in einer Datei endet dies in einem unglücklichen Hang. In beiden Fällen müssen Sie den Computer neu starten. Ich bin froh, dass gleichzeitig die Datendatei nicht zu immensen Größen anschwillt.



Das Kraftway-BIOS mit ASRock H81M-DGS-Karte erwies sich als sehr eigensinnig. Es reagiert also auf Strg Alt Del Del, indem es hängt, von dem nur Reset es ausgeben kann. Beim Überspringen des Startskripts <startup.nsh> in Shell'e gab es Probleme - ein Sekundenbruchteil anstelle von fünf Standard-Skripten. Vielleicht werden diese Probleme durch die Modifikation durch die proprietären KSS-Module verursacht, vielleicht ist die Angelegenheit ME ungenau "abgeschraubt".

Auf der Asus H97-PLUS-Karte verfügt die Firmware über die folgende Funktion: BootOrder läuft mit der Zeit über. Der Grund liegt höchstwahrscheinlich in den Fehlern im Code. Vielleicht wollte der Hersteller zwar alle Boot-Geräte, die jemals angeschlossen waren, im Board behalten, rechnete aber nicht damit, dass an einem Tag mehr als ein Dutzend vorhanden sein könnten. Wenn BootOrder überläuft, bleibt das System während des Startvorgangs hängen. Um es zu reinigen, müssen Sie alle Startgeräte ausschalten und das System einschalten. Die Firmware löscht sich von selbst und das System startet direkt in der BIOS-Setup-Shell. Die Leistung bleibt bis zum nächsten Überlauf erhalten.

Wenn Sie die Erfahrung mit Boards verschiedener Anbieter zusammenfassen, kommen Sie zu dem Schluss, dass es fast unmöglich ist herauszufinden, mit welchen Überraschungen auf EFI-Ebene Sie auf dem nächsten Board umgehen werden, selbst wenn es bereits ein bekanntes Modell hat. Dies ist eine Art Lotterie, da manchmal Schwierigkeiten beim Sammeln von Informationen über das System auftreten können. Vielleicht hat dies einen unauslöschlichen Forschungsidealismus und das Vertrauen in den Hersteller, denn wie sonst könnten einige der frischesten Motherboards mit ME v11 und v12 hängen, wenn FPT oder MEInfo älterer Versionen darauf ausgeführt werden?

Probleme bei der Arbeit mit Hardwareprotokollen




Einige Probleme treten auf, wenn wir mit USB-Geräten arbeiten - Laufwerken und Token. Dies geschieht häufig, weil der BIOS-Code für die Arbeit mit Peripheriegeräten ein gefährlicher Cocktail aus Treibern und Anwendungen von Independent Hardware Vendor (IHV) für ein bestimmtes Peripheriegerät ist, Code vom Chipsatzhersteller (in unserem Fall von Intel), Code vom BIOS-Hersteller und Code vom Hersteller des Motherboards.

Die folgenden „interessanten“ Situationen sind

aufgetreten : Token „nicht erkannt“. Gleichzeitig leuchtet eine LED darauf. Höchstwahrscheinlich durchläuft der Host-Controller den anfänglichen Rücksetzvorgang des USB-Geräts nicht, dh die Stromversorgung wird bereitgestellt, aber das Zurücksetzen durch Ändern der D + - und D- -Leitungen funktioniert nicht ordnungsgemäß, und ohne ihn sind weitere Manipulationen mit dem Token bedeutungslos.

Der Computer friert vor dem Laden der Shell ein (erneut mit angeschlossenem Token). In diesem Fall startet der PC ohne Token normal. Live sieht es so aus: Der Computer scheint direkt nach dem Start abzustürzen, während der Token im Anschluss herausragt. Sie nehmen es heraus - das Laden geht plötzlich weiter. Verbinden - wieder hängen. Das offensichtliche Problem liegt in der UEFI, und man kann nur über die Gründe spekulieren.

Die Situation, in der es nicht möglich ist, die USB_IO-Schnittstelle zu öffnen. Möglicherweise ist es nur mit der Schnittstelle für die Arbeit mit Smartcards verbunden - USB CCID. Einige AMI-Treiber haben USB_IO bereits mit dem Parameter EFI_OPEN_PROTOCOL_BY_DRIVER geöffnet. Der Treiber hat ein Protokoll mit einer 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
	 );
 }

BindingStop () wird jedoch nicht aufgerufen, d.h. Das Geräteextraktionsereignis wird nicht überwacht, und der Treiber versucht, ein ungültiges Handle zu verwenden. Dies wurde mit dem HP Compaq Elite 8300 SFF PC und einigen anderen beobachtet. Dies ist entweder eine Art Herstellerschutz vor unerwünschten Treibern oder ein regelmäßiger Entwicklungsfehler. Vielleicht unternimmt AMI ständig etwas in Richtung USB CCID, aber der störende Treiber kann nicht entladen werden, da er sich zusammen mit USB HID, USB MassStorage, im selben AMI UHCI-Modul befindet. Mit UninstallInterface () sieht es ähnlich aus.

Oder eine andere interessante Funktion. In einem der UEFI-BIOS, in dem das Token nicht erkannt wurde, durfte USB_IO die Gerätedeskriptoren lesen, EFI_INVALID_PARAMETER kehrte jedoch zum nächsten UsbBulkTransfer () zurück. Darüber hinaus geschah dies nur mit einigen Arten von Token, mit absolut den gleichen Parametern, andere funktionierten perfekt.

Im Allgemeinen ist das Protokoll UsbBulkTransfer () interessanterweise im EFI_USB_IO_PROTOCOL-Protokoll implementiert. Es ist für eine garantierte Paketzustellung für eine unbegrenzte Zeit oder für die im Parameter Timeout angegebene Zeit vorgesehen. Es wurde jedoch ein Experiment mit einem MassStorage-Gerät durchgeführt: Beim Kopieren einer großen Datei auf ein USB-Flash-Laufwerk wurde diese entfernt. PC hängt fest. Beim Anschließen des USB-Flash-Laufwerks sackte der PC zusammen und schrieb die Datei weiter, als wäre nichts passiert. Die gleiche Situation war mit Token, aber mit seinen eigenen Besonderheiten. Dies ist ein Architekturproblem. In EFI gibt es außer einem Timer keine Interrupts, und die Geräte arbeiten gemäß einer Umfrage. Das heißt, das System stürzte irgendwo in der USB-Abfrage ab, erreichte jedoch nicht die Zeitüberschreitungsausgabe. Als das Gerät erneut angezeigt wurde, wurde es einfach fortgesetzt und der Vorgang abgeschlossen.

Virtualisierung


Wir sollten auch über virtuelle Umgebungen sagen. Derzeit gibt es zwei Hauptplattformen auf dem Markt, die die Emulation der EFI-Umgebung unterstützen: VMware und VirtualBox. Beide haben ihre Vor- und Nachteile bei der Interaktion mit ihnen wie bei „echten“ Systemen. Die VMware-Umgebung bietet ausreichend Arbeit mit NVRAM-Variablen, stolpert jedoch bei der visuellen Anzeige von Nachrichten während der Initialisierung von DXE-Modulen: Im besten Fall werden native Nachrichten bevorzugt, um bootfähige Medien zu finden und das zu hinterlassen, was wir benötigen. VirtualBox hingegen rendert alles, was erforderlich ist, perfekt, möchte sich aber nicht an lange Variablen erinnern.

Ein weiterer kleiner Stein im VMware-Garten - der integrierte FAT32-Treiber unterstützt das Erstellen und Bearbeiten von Dateien nur in 8.3-Notation. Es ist nicht klar, warum dies getan wurde, aber dies ist eine Einschränkung, die eindeutig Aufmerksamkeit erfordert. Es ist wahrscheinlich, dass eine ähnliche Implementierung des Treibers auf realen Plattformen beobachtet werden kann, aber bisher sind wir nicht auf diese gestoßen.

Auf der anderen Seite gibt es in virtuellen Maschinen keine Tänze mit Firmware-Dienstprogrammen, Programmierern, Jumpern und unbequemen Chips. Eine separate ROM-Datei, UEFITool und eine Zeile in der Konfigurationsdatei. Fast eine Idylle.

Schlussendlich



Ein Ausschnitt aus der Anfrage von CHIPSEC. Wo lehren sie solche Sakramente?

Wie bereits erwähnt, ist die Entwicklung und Implementierung in der UEFI-Shell ein faszinierender und kreativer Prozess. Selbst auf einem berühmten Feld kann man immer auf etwas Neues stoßen. Einerseits ist es ermutigend, dass sich der Standard weiterentwickelt, andererseits ist es traurig, dass konkrete Implementierungen durch die Produzenten zu „kreativ“ sind.

Die Hauptprobleme waren und sind:

  1. Abweichung von Anbietern von der UEFI-Spezifikation bei der Entwicklung der Firmware.
  2. Fehler im Code während der Implementierung.
  3. NDV im Code, Popup während der Integration.

Und nicht zuletzt das Fehlen vieler Dinge in der offiziellen (gelesenen, offenen) Dokumentation, wie zum Beispiel Beschreibungen des Protokolls für die Kommunikation mit ME über PCI-Geräte wie MEI, HECI. Sie finden eine Beschreibung der Register, jedoch nicht der Befehle. Finden Sie eine GUID, aber nicht ihren Zweck. Dies führt erneut zu einer langen Analyse, bei der Daten und Statistiken auf Plattformen gesammelt und der Disassembler verwendet werden.

Es sollte angemerkt werden, dass sich die Situation langsam aber sicher korrigiert, und ich möchte glauben, dass der Moment nicht weit entfernt ist, in dem die Entwicklung des Standards zu einem ziemlich vorhersehbaren und sehr angenehmen Prozess wird.

Vladimir Onipchuk,
Leiter der Gruppe der Hardware- und Softwareschutzprodukte von
Gazinformservice LLC

More articles:


All Articles