Eine Reise durch die Geheimnisse der Firmware: Vom BIOS/UEFI zum Betriebssystem

Haben Sie sich schon einmal gefragt, was passiert, wenn Sie den Einschaltknopf Ihres Computers drücken? In dieser kurzen Pause, bevor Ihr Bildschirm aufleuchtet, findet eine komplexe Reihe von Prozessen statt. Dieser Artikel taucht in die faszinierende ein und untersucht, wie . Welt der Firmware verschiedene Komponenten während des Startvorgangs interagieren Wenn Sie diese Zusammenhänge verstehen, erhalten Sie ein klareres Bild der grundlegenden Elemente, die Ihr System zum Leben erwecken. Unser Hauptaugenmerk liegt auf der , aber viele Prinzipien gelten auch für andere Architekturen. Intel x86-Architektur Wenn Sie den ersten Teil unserer Serie verpasst haben, , um ihn nachzuholen. klicken Sie hier Lassen Sie uns nun die Geheimnisse hinter der Firmware lüften. Inhaltsverzeichnis: Definitionen Allgemeine Firmware-Architektur Bootloader der ersten Stufe (FSBL) BIOS (POST-Phase) UEFI-Plattforminitialisierung (PI) coreboot Andere Lösungen Bootloader der zweiten Stufe (SSBL) BIOS UEFI Betriebssystem-Bootloader Definitionen : Ein spezieller Typ von Software, der in die Hardware eingebettet ist, eine Steuerung auf niedriger Ebene bietet und die korrekte Funktion der Hardware sowie die Interaktion mit anderen Systemkomponenten ermöglicht. Firmware : eine ältere Firmware (ursprünglich für den entwickelt), die für die Initialisierung der Hardware nach dem Einschalten der Plattform verantwortlich ist. Heutzutage wird es oft vage als vollständiger Satz der Firmware bezeichnet. Basic Input/Output System (BIOS) IBM PC : eine allgemeine Bezeichnung für Firmware, die für das Booten eines Computers verantwortlich ist. Es wird als modernes Konzept anstelle des verwendet und bietet häufig ein mit Bootstrap-Code zum Initialisieren des Prozessors und des Chipsatzes sowie Schnittstellen für Dritte (z. B. Motherboard-Entwickler), um eine plattformspezifische Initialisierung durchzuführen. Bootloader BIOS Framework : Eine Software, die ausgeführt werden soll, wenn der Bootloader beendet wird. Dies kann ein Bootloader der zweiten Stufe, ein Betriebssystem, eine BIOS/UEFI-Anwendung usw. sein. Normalerweise kümmert sie sich um den Bootstrapping-Flow gemäß dem Firmware-Design. Payload Die Verwendung der Begriffe und kann verwirrend sein, da ihre Bedeutung kontextabhängig ist. Wenn jedoch jemand , oder erwähnt, bezieht er sich im Allgemeinen auf . BIOS Bootloader Firmware BIOS Bootloader den vollständigen Satz der Firmware, der zwischen dem Betriebssystem und der Hardware ausgeführt wird vs. : Das war die ursprüngliche Spezifikation, die von Intel entwickelt wurde. Das ist der Nachfolger von und wurde vom entwickelt, um die ursprüngliche Spezifikation zu standardisieren und zu erweitern. In den meisten Fällen werden und synonym verwendet. EFI UEFI Extensible Firmware Interface (EFI) Unified Extensible Firmware Interface (UEFI) EFI UEFI-Forum EFI UEFI Allgemeine Firmware-Architektur Um zu verstehen, wie die Firmware-Komponenten interagieren, werden wir die gesamte Architektur mit allen verbundenen Teilen untersuchen. Der Ausführungsfluss, der im folgenden Diagramm dargestellt ist, beginnt mit dem , der Teil des ist. Von dort aus durchläuft er verschiedene Firmware-Phasen: Reset-Vektor First-Stage-Bootloaders Firmware oder BIOS können im Allgemeinen in zwei Hauptteile unterteilt werden, zwischen denen normalerweise nur eine minimale Schnittstelle besteht: : Verantwortlich für die Initialisierung der Hardwarekomponenten des Systems. Hardwareinitialisierung : Bietet die erforderlichen Schnittstellen zum Betriebssystem und zum Benutzer. Schnittstelle zum Betriebssystem und Benutzer Das Design der Plattform-Firmware kann entweder sein und Hardwareinitialisierung und Startfunktionalität kombinieren oder einem und folgen. Die Wahl des Designs hängt von den Systemanforderungen ab und kann für bestimmte Geräte vorzuziehen sein. monolithisch modularen stufenweisen Startablauf Das folgende Diagramm veranschaulicht, wie verschiedene Firmware-Komponenten interagieren und gemeinsam verwendet werden können, um den Startvorgang zu unterstützen (Pfeile zeigen die Ausführungsreihenfolge an): Machen Sie sich keine Sorgen, wenn Ihnen diese Diagramme jetzt kompliziert erscheinen. Sehen Sie sie sich nach dem Lesen dieses Artikels noch einmal an, dann werden sie klarer. Bootloader der ersten Stufe (FSBL) Diese Firmware dient zum Initialisieren von Computern und eingebetteten Systemen mit einem : Es wird nur das getan, was unbedingt nötig ist, und dann wird die Kontrolle an übergeben, um das Betriebssystem zu booten. Der lädt keine Betriebssysteme von anderen Speichermedien als dem . Da er nur die zugrunde liegende Hardware initialisiert und keine Bootmedien wie Festplatten, SSDs oder USB-Flash-Laufwerke verarbeitet, ist ein weiteres Stück Software erforderlich, um ein tatsächlich zu booten. Schwerpunkt auf minimaler Hardware-Initialisierung den Second-Stage Bootloader FSBL Flash-Chip Betriebssystem : Hauptaufgaben von FSBL : Wechseln vom 16-Bit- in den 32-Bit ( : oder im BIOS in den ). CPU Realmodus -geschützten Modus Hinweis virtuellen 8086-Modus : Aufruf um für die zu konfigurieren. Cache-Auslastung von FSP-T, Cache-As-RAM C-Umgebung : Initialisieren des konfigurierten Debug-Ports durch Aufrufen platinenspezifischer Initialisierungsmethoden. Debug-Port : Aufrufen von um den Hauptspeicher des Systems zu initialisieren und wichtige Systemspeicherinformationen zu speichern. Speicherinitialisierung FSP-M, : Konfigurieren von GPIO-Pins (General-Purpose Input/Output) für die Schnittstelle mit externen Geräten. GPIO : Durchführen einer frühen Plattforminitialisierung und Verwenden von zum Abschließen der Initialisierung von Chipsatz, CPU und IO-Controller. Silizium FSP-S : Aufzählung von PCI-Geräten und Zuweisung von Ressourcen wie Speicheradressen und IRQs. PCI-Aufzählung : Einrichten von und Tabellen, einschließlich der Vorbereitungsinformationen (Coreboot-Tabellen, HOBs), die an die Nutzlast übergeben werden müssen. Vorbereitung der Nutzlast SMBIOS- ACPI- : Laden und Übergeben der Kontrolle an die Nutzlast. Laden und Übergabe BIOS (POST-Phase) In den frühen Tagen der Computertechnik war Open-Source-Software nicht sehr beliebt und die meisten BIOS-Implementierungen waren proprietär. Es gibt nur wenige verfügbare offene Lösungen, die BIOS-POST-Quellcode bereitstellen, wie und . Diese Projekte wurden für die Verwendung auf IBM 5150/5155/5160-Systemen und den meisten XT-Klonen entwickelt. Super PC/Turbo XT BIOS GLaBIOS Die bekannteren Open-Source-BIOS-Implementierungen wie und führen jedoch keine Hardware-Initialisierung durch, da sie nicht für die Ausführung auf nackter Hardware vorgesehen sind. Sie werden jedoch häufig als verwendet und laufen nativ in virtuellen Umgebungen wie QEMU und Bochs. OpenBIOS SeaBIOS Second-Stage-Bootloader In jedem Fall besteht kaum die Möglichkeit, dass Sie direkt mit diesen frühen BIOS arbeiten oder sich eingehend mit deren Besonderheiten befassen müssen. Wenn Sie sich jedoch näher damit befassen möchten, sind die genannten Repositories ein guter Ausgangspunkt. Was die aktuellen Entwicklungstrends angeht, scheint es keine Weiterentwicklung proprietärer BIOS-Lösungen zu geben und solche Projekte sind angesichts moderner Alternativen obsolet geworden. UEFI-Plattforminitialisierung (PI) Der Startvorgang folgt einem schrittweisen Ablauf, der in der nächsten Abbildung von links nach rechts beginnt. Die Zeitleiste des Plattformstartvorgangs ist in die folgenden Abschnitte unterteilt, die durch gelbe Kästchen angezeigt werden: : Die erste Phase nach einem , ihre Hauptfunktion besteht darin, temporären RAM (CPU- oder SRAM) einzurichten. Sicherheit (SEC) Reset-Vektor Cache-As-RAM : In dieser Phase werden spezielle Treiber, sogenannte gestartet. Diese Module übernehmen die grundlegende Initialisierung der Hardware, z. B. die Konfiguration der CPU und des Chipsatzes sowie die Einrichtung . Pre-EFI-Initialisierung (PEI) Pre-EFI-Initialisierungsmodule (PEIMs), des Hauptspeichers (DRAM) : In dieser Phase wird die restliche Systeminitialisierung durchgeführt. Die DXE-Phase stellt bereit und unterstützt verschiedene Protokolle und Treiber, die für den Betrieb des Systems erforderlich sind. Driver Execution Environment (DXE) UEFI-Dienste : In dieser Phase wird die Startrichtlinie der Plattform implementiert, die Startreihenfolge bestimmt und das entsprechende Startgerät/den entsprechenden Bootloader ausgewählt. Boot Device Select (BDS) : Während dieser Phase führt das System Anwendungen mithilfe von UEFI-Diensten aus, um das Betriebssystem vorzubereiten. Dies umfasst den Übergang von der UEFI-Umgebung zum Betriebssystem und endet mit dem Aufruf von . Transient System Load (TSL) ExitBootServices() : In dieser Phase ist das Betriebssystem voll funktionsfähig und verwaltet das System unter seiner Kontrolle. Laufzeit (RT) : In dieser Phase geht es um Szenarien, in denen die Hardware oder das Betriebssystem abstürzt/herunterfährt/neu startet. Die Firmware kann Wiederherstellungsmaßnahmen versuchen, die UEFI PI-Spezifikation definiert jedoch keine spezifischen Anforderungen oder Verhaltensweisen für diese Phase. After Life (AL) Dieser Prozess und seine Ausführungsphasen werden in der behandelt. Es gibt jedoch auch die (im Bild durch die fette blaue Linie gekennzeichnet), die nicht Teil des vorherigen Dokuments ist und in der beschrieben wird. Obwohl die Namen und die häufige Verwendung von verwirrend sein können, haben diese beiden Dokumente unterschiedliche Schwerpunkte: UEFI Platform Initialization (PI) Specification UEFI-Schnittstelle UEFI Specification UEFI : Konzentriert sich auf Schnittstellen zwischen Low-Level-Firmwarekomponenten und beschreibt im Detail, wie diese Module interagieren, um die Plattform zu initialisieren. UEFI PI-Spezifikation : Definiert die Schnittstellen für die Interaktion zwischen dem Betriebssystem (OS) und der Firmware. Dies wird im Zusammenhang mit dem ausführlicher erläutert. Beachten Sie, dass die UEFI-Spezifikation auf der PI-Spezifikation basiert. UEFI-Spezifikation Second-Stage-Bootloader Im Wesentlichen geht es in beiden Spezifikationen um Schnittstellen, allerdings auf unterschiedlichen Ebenen. Ausführliche Informationen zu beiden Spezifikationen finden Sie auf der . Website des UEFI-Forums wurde ursprünglich als einheitliche Firmware-Lösung entwickelt, ohne die Unterscheidung zwischen Bootloadern der ersten und zweiten Stufe zu berücksichtigen. Wenn wir jedoch als bezeichnen, umfasst dies die Phasen , und . Der Grund, warum wir DXE in und Phasen unterteilen, liegt in ihren unterschiedlichen Rollen im Initialisierungsprozess. UEFI PI UEFI Bootloader der ersten Stufe SEC PEI frühe DXE frühe späte In der Phase führen Treiber normalerweise die grundlegende Initialisierung von CPU/PCH/Board durch und erstellen außerdem , die dabei helfen, die DXE-Phase von der plattformspezifischen Hardware zu isolieren. kapseln die plattformspezifischen Details ein, sodass die Phase unabhängig von den Hardwarespezifikationen ausgeführt werden kann. frühen DXE- DXE Architectural Protocols (APs) APs späte DXE- Coreboot Detaillierte Artikel zur Funktionsweise von Coreboot folgen in Kürze. Folgen Sie mir auf den sozialen Medien – sie werden in Kürze veröffentlicht! Andere Lösungen : reiner Bootloader der ersten Stufe, der nur die Initialisierung der Kernhardwarekomponenten und anschließend das Laden der Nutzlast ermöglicht. und unterstützt weder AMD x86 noch andere Architekturen. Intel Slim Bootloader (SBL) Funktioniert jedoch nur auf Intel x86-Plattformen : sowohl ein Bootloader der ersten als auch der zweiten Stufe. Die Unterstützung für das direkte Booten vom x86- der Plattform (bekannt als Bare-Modus) ist jedoch im Vergleich zu anderer Firmware eingeschränkt. Es ist beliebter auf eingebetteten Systemen und ARM-basierten Geräten. Als Bootloader der zweiten Stufe implementiert U-Boot eine konzentriert sich jedoch auf eingebettete Systeme. Das U-Boot Reset-Vektor Teilmenge des UEFI, Bootloader der zweiten Stufe (SSBL) Nach Abschluss der anfänglichen Hardwareeinrichtung kommt die ins Spiel. Ihre Hauptaufgabe besteht darin, eine einzurichten und sicherzustellen, dass das Betriebssystem Systemressourcen verwalten und mit Hardwarekomponenten interagieren kann. zweite Phase Softwareschnittstelle zwischen dem Betriebssystem und der Plattform-Firmware Das Ziel des besteht darin, und die Entwicklung von Betriebssystemen und Anwendungen zu vereinfachen, indem die meisten Schnittstellen auf Hardwareebene verwaltet werden. Diese Abstraktion ermöglicht es Entwicklern, sich auf Funktionen auf höherer Ebene zu konzentrieren, ohne sich um die zugrunde liegenden Hardwareunterschiede kümmern zu müssen. SSBL Hardwarevariationen so weit wie möglich zu verbergen : Hauptaufgaben von SSBL : Ruft plattformspezifische Informationen vom ab, einschließlich Speicherzuordnung, SMBIOS, ACPI-Tabellen, SPI-Flash usw. Abrufen von Plattforminformationen First-Stage-Bootloader : Enthält Treiber für SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, Netzwerkschnittstellen usw. Plattformunabhängige Treiber ausführen : Bietet eine Reihe von Diensten, die die Kommunikation zwischen dem Betriebssystem und den Hardwarekomponenten erleichtern. Implementierung von Diensten (auch Schnittstelle genannt) : Bietet ein Setup-Menü zur Systemkonfiguration, in dem Benutzer Einstellungen bezüglich Startreihenfolge, Hardwareeinstellungen und anderen Systemparametern anpassen können. Setup-Menü : Mechanismus zum Lokalisieren und Laden der Nutzlast (wahrscheinlich Betriebssystem) von verfügbaren Boot-Medien. Boot-Logik BIOS Die Schnittstelle im BIOS wird als bezeichnet. Diese Funktionen stellen eine Reihe von Routinen für den Hardwarezugriff bereit, aber die spezifischen Details ihrer Ausführung auf der jeweiligen Hardware des Systems sind für den Benutzer verborgen. BIOS-Dienste/Funktionen/Interruptaufrufe Im 16-Bit- können sie einfach durch Aufrufen eines Software-Interrupts über -x86-Assemblersprachenbefehl aufgerufen werden. Im 32-Bit- sind aufgrund der unterschiedlichen Verarbeitung von fast alle BIOS-Dienste nicht verfügbar. Realmodus einen INT geschützten Modus Segmentwerten Als Beispiel für die Verwendung dieser Schnittstelle nehmen wir beispielsweise ( ), das sektorbasierte Lese- und Schreibdienste für Festplatten und Disketten unter Verwendung -Adressierung bereitstellt. Angenommen, wir möchten 2 Sektoren (1024 Bytes) lesen und sie an der Speicheradresse laden, dann könnte der folgende Code ausgeführt werden: Disk Services INT 13h der Cylinder-Head-Sector (CHS) 0x9020 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code Wenn Sie wissen möchten, wie dieser Dienst in SeaBios geschrieben ist, sehen Sie sich an. src/disk.c BOOT-Phase Beginnt mit der Suche nach einem (es kann eine Festplatte, CD-ROM, Diskette usw. sein), indem der (Sektor Null) von den Geräten gelesen wird. bootfähigen Gerät erste 512-Byte-Sektor Die Bootstrap-Sequenz im BIOS lädt den ersten gültigen , den sie findet, in den physischen Speicher des Computers an der Adresse (Hinweis: und beziehen sich auf dieselbe physische Adresse). Master Boot Record (MBR) physischen 0x7C00 0x0000:0x7c00 0x7c0:0x0000 Das BIOS überträgt die Kontrolle auf die der Nutzlast. Dieser , der zu klein ist, um den gesamten Nutzlastcode aufzunehmen, dient dazu, den Rest der Nutzlast vom zu laden. An diesem Punkt kann die Nutzlast die vom BIOS freigegebene Schnittstelle verwenden. ersten 512 Bytes geladene Sektor bootfähigen Gerät Es ist bemerkenswert, dass es damals noch . BIOS ist ein – es funktioniert so, wie es in den 1980er Jahren auf echten IBM-PCs funktionierte. Die übrigen Hersteller haben einfach und IBM-kompatible BIOSe erstellt. Daher gab es keine Regelung, die BIOS-Hersteller daran hinderte, neue BIOS-Funktionen zu entwickeln oder überlappende Funktionalitäten einzuführen. keine BIOS-Spezifikationen gab De-facto-Standard Reverse Engineering betrieben Einheitliche erweiterbare Firmware-Schnittstelle (UEFI) Wie bereits erwähnt, ist UEFI selbst nur eine Spezifikation und verfügt über viele Implementierungen. Die am weitesten verbreitete ist , eine Open-Source- der UEFI- und PI-Spezifikationen. Obwohl EDKII allein nicht ausreicht, um eine voll funktionsfähige Boot-Firmware zu erstellen, bietet es eine solide Grundlage für die meisten kommerziellen Lösungen. TianoCore EDK II Referenzimplementierung Um verschiedene zu unterstützen und eine UEFI-Schnittstelle bereitzustellen, wird das -Projekt verwendet. Es basiert auf der anfänglichen Einrichtung und den von der Boot-Firmware bereitgestellten Plattforminformationen, um das System für die UEFI-Umgebung vorzubereiten. First-Stage-Bootloader UEFI-Payload Die UEFI-Nutzlast verwendet die und Phasen, die plattformunabhängig konzipiert sind. Sie bietet eine generische Nutzlast, die sich an verschiedene Plattformen anpassen lässt. In den meisten Fällen sind keine Anpassungen oder plattformspezifischen Anpassungen erforderlich und sie kann unverändert verwendet werden, indem Plattforminformationen vom verwendet werden. DXE- BDS- First-Stage-Bootloader : Varianten der UEFI-Nutzlast : Erfordert eine Parse-Bibliothek, um erforderliche implementierungsspezifische Plattforminformationen zu extrahieren. Wenn der Bootloader seine API aktualisiert, muss auch die Payload aktualisiert werden. Legacy-UEFI-Payload : Befolgt die und verwendet oder als gemeinsames Bildformat. Anstatt sie selbst zu analysieren, erwartet es, die beim Nutzlasteintrag zu erhalten. Universelle UEFI-Nutzlast Universal Scalable Firmware (USF)-Spezifikation Executable and Linkable Format (ELF) Flat Image Tree (FIT) Hand Off Blocks (HOBs) Während die gut funktioniert, versucht die EDK2-Community, die Branche in Richtung zu bewegen. Die Wahl zwischen den Payloads hängt von Ihren Firmware-Komponenten ab. Beispielsweise ist es nicht möglich, die auf ohne auszuführen. Andererseits erfordert die Verwendung der mit Coreboot eine Shim-Schicht, um in zu übersetzen, eine Funktion, die nur im verfügbar ist. Legacy UEFI Payload Universal UEFI Payload Legacy Payload mit SMM-Unterstützung Slim Bootloader meinen Patch Universal Payload Coreboot-Tabellen HOBs StarLabs EDK2-Fork Schnittstelle Jedes UEFI-kompatible System stellt eine bereit, die an jeden Code weitergegeben wird, der in der UEFI-Umgebung ausgeführt wird (Treiber, Anwendungen, Betriebssystemlader). Diese Datenstruktur ermöglicht einer UEFI-ausführbaren Datei den Zugriff auf wie , und eine Sammlung von . Systemtabelle Systemkonfigurationstabellen ACPI SMBIOS UEFI-Diensten Die Tabellenstruktur wird in beschrieben: MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; Zu den Diensttypen gehören die folgenden: , und . Boot-Dienste Runtime-Dienste durch Protokolle bereitgestellte Dienste UEFI abstrahiert den Zugriff auf das Gerät durch die Einrichtung . Diese und durch einen identifiziert werden, der es anderen Modulen ermöglicht, sie zu finden und zu verwenden. Sie können über Boot Services ermittelt werden. von UEFI-Protokollen Protokolle sind Datenstrukturen, die Funktionszeiger enthalten Globally Unique Identifier (GUID) Ein erstellt diese Protokolle und die eigentlichen Funktionen (keine Zeiger!) sind im Treiber selbst enthalten. Dieser Mechanismus ermöglicht es verschiedenen Komponenten innerhalb der UEFI-Umgebung, miteinander zu kommunizieren, und stellt sicher, dass das Betriebssystem mit Geräten interagieren kann, bevor es seine eigenen Treiber lädt. UEFI-Treiber Während einige Protokolle vordefiniert und in der UEFI-Spezifikation beschrieben sind, können Firmware-Anbieter auch um die Funktionalität einer Plattform zu erweitern. eigene benutzerdefinierte Protokolle erstellen, Boot-Dienste Stellen Sie Funktionen bereit, die während des Startvorgangs verwendet werden können. Diese Dienste bleiben verfügbar, bis die Funktion aufgerufen wird ( ). nur EFI_BOOT_SERVICES.ExitBootServices() MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c Zeiger auf alle Boot-Dienste werden in der ( ) gespeichert: Boot Services Table MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES; Laufzeitdienste Ein minimaler Satz von Diensten ist weiterhin zugänglich, während das Betriebssystem ausgeführt wird. Im Gegensatz zu Boot Services sind diese Dienste weiterhin gültig, nachdem eine Nutzlast (z. B. der OS-Bootloader) über einen Aufruf von die Kontrolle über die Plattform übernommen hat. EFI_BOOT_SERVICES.ExitBootServices() Zeiger auf alle Laufzeitdienste werden in ( ) gespeichert: der Runtime Services Table MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES; Das Bild unten zeigt die Zeitleiste für Boot- und Laufzeitdienste, sodass Sie genau sehen können, wann jeder aktiv ist. Boot Device Select (BDS)-Phase Die UEFI-Spezifikation definiert eine Boot-Policy-Engine namens . Sie versucht in einer bestimmten Reihenfolge zu laden. Diese Reihenfolge und andere Einstellungen können durch Ändern globaler konfiguriert werden. Lassen Sie uns die wichtigsten davon besprechen: UEFI-Boot-Manager , UEFI-Anwendungen NVRAM-Variablen (Non-Volatile Random-Access Memory) ( wird durch einen eindeutigen Hex-Wert ersetzt) – eine Boot-/Ladeoption. Boot#### #### – die Startoption zum Starten des aktuell laufenden Systems. BootCurrent – die Startoption nur für den nächsten Start. Dies ersetzt nur für einen Start und wird vom Bootmanager nach der ersten Verwendung gelöscht. Auf diese Weise können Sie das nächste Startverhalten ändern, ohne zu ändern. BootNext BootOrder BootOrder – die geordnete Ladeliste der Startoptionen. Der Bootmanager versucht, die erste aktive Option in dieser Liste zu starten. Wenn dies nicht gelingt, versucht er es mit der nächsten Option und so weiter. BootOrder – die vom Boot-Manager unterstützten Arten von Boot-Optionen. BootOptionSupport – das Timeout des Bootmanagers der Firmware in Sekunden, bevor automatisch der Startwert aus oder ausgewählt wird. Timeout BootNext BootOrder Diese Variablen können einfach unter Linux mit abgerufen werden: efibootmgr(8) [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Sehen wir uns das Booten anhand des obigen Codeausschnitts an. UEFI beginnt mit der Iteration der -Liste. Für jeden Eintrag in der Liste sucht es nach einer entsprechenden -Variable – für 0000, für 2003 und so weiter. Wenn die Variable nicht vorhanden ist, wird mit dem nächsten Eintrag fortgefahren. Wenn die Variable vorhanden ist, wird der Inhalt der Variablen gelesen. Jede Bootoptionsvariable enthält einen Deskriptor, der ein byteweise gepackter Puffer mit Feldern variabler Länge ist (es ist nur die Datenstruktur). BootOrder Boot#### Boot0000 Boot2003 EFI_LOAD_OPTION Die Datenstruktur ist in [MdePkg/Include/Uefi/UefiSpec.h][ ] beschrieben. https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION; An diesem Punkt untersucht die Firmware einen ( ). In den meisten Fällen wird unser Computer von einem Speichergerät (Festplatte/SSD/NVMe/usw.) hochgefahren. Der würde also den Knoten enthalten. Gerätepfad EFI_DEVICE_PATH_PROTOCOL Gerätepfad HD(Partition Number, Type, Signature, Start sector, Size in sectors) — gibt das für das Partitionierungsschema verwendete Format mit den Schlüsselwörtern (1) oder (2) an. Typ MBR GPT – eine 4-Byte-MBR-Signatur, wenn der Typ ist, oder eine 16-Byte- , wenn der Typ ist. Signatur MBR UUID GPT : Wenn Sie wissen möchten, wie andere Pfade übersetzt werden, lesen Sie . Hinweis die UEFI-Spezifikation v2.10, 10.6.1.6 Text Device Node Reference UEFI prüft die Festplatte und sucht nach einer Partition, die mit dem Knoten übereinstimmt. Wenn dies der Fall ist, sollte sie mit einem bestimmten gekennzeichnet sein, der sie als kennzeichnet. Diese ist mit einem Dateisystem formatiert, dessen Spezifikation auf der spezifischen Version des basiert und heißt; eigentlich ist es nur ein normales . Globally Unique Identifier (GUID) EFI-Systempartition (ESP) FAT-Dateisystems EFI-Dateisystem FAT12/16/32 : Wenn der einen expliziten Pfad zur Datei enthält, sucht UEFI nach dieser bestimmten Datei. Beispielsweise enthält die Option . Nativer Start Gerätepfad File(\Path\To\The\File.efi) Boot0000 File(\EFI\ARCHLINUX\grubx64.efi) : Wenn der einfach auf eine Festplatte verweist, verwendet die Firmware in solchen Situationen einen , der auf der Architektur basiert – ( für oder für / ). Dieser Mechanismus ermöglicht es (z. B. einem USB-Laufwerk), in UEFI zu funktionieren; sie verwenden einfach einen . Beispielsweise verwendet die Option diesen Mechanismus. Fallback-Boot Gerätepfad Fallback-Boot-Pfad \EFI\BOOT\BOOT{arch}.EFI BOOTx64.EFI amd64 BOOTia32.EFI i386 IA32 bootfähigen Wechselmedien Fallback-Boot-Pfad Boot0002 Alle oben genannten Optionen beziehen sich auf die Boot-Optionen, die in der Beispielausgabe von angezeigt werden. Hinweis: Boot#### efibootmgr In beiden Fällen lädt der die (das kann , die UEFI-Shell, Dienstprogramme, das System-Setup usw. sein) in den Speicher. In diesem Moment wird die Kontrolle dann an den Einstiegspunkt der übertragen. Anders als kann die die Kontrolle an die Firmware zurückgeben (außer in der Situation, in der die Anwendung die Kontrolle über das System übernimmt). Wenn dies geschieht oder etwas schief geht, fährt der mit dem nächsten Eintrag fort und folgt genau demselben Prozess. UEFI-Bootmanager UEFI-Anwendung der OS-Bootloader UEFI-Anwendung das BIOS UEFI-Anwendung Bootmanager Boot#### In der Spezifikation wird erwähnt, dass der die Datenbankvariablen automatisch verwalten kann. Dazu gehört das Entfernen von Ladeoptionsvariablen, die nicht referenziert werden oder nicht analysiert werden können. Darüber hinaus kann er jede geordnete Liste neu schreiben, um alle Ladeoptionen ohne entsprechende Ladeoptionsvariablen zu entfernen. Bootmanager Der obige Text beschreibt den . Außerdem kann die UEFI-Firmware im -Modus ausgeführt werden, der ein BIOS emuliert. UEFI-Bootvorgang Compatibility Support Module (CSM) Betriebssystem-Bootloader Eine Software, die von der Firmware gestartet wird (normalerweise ) und deren Schnittstelle zum verwendet. Sie kann so komplex wie ein Betriebssystem sein und Funktionen bieten wie: Second-Stage Bootloader Laden des Betriebssystemkernels Lesen aus verschiedenen Dateisystemen (HFS+, ext4, XFS usw.) Interaktion über ein Netzwerk (z. B. TFTP, HTTP) Booten von -kompatiblen Kerneln Multiboot Kettenladen Laden der ersten Ramdisks ( ) initrd Und mehr! Die allgemeinen Designs dieser Programme gehen über den Rahmen dieses Artikels hinaus. Einen detaillierten Vergleich beliebter Betriebssystem-Bootloader finden Sie im und im . ArchLinux-Wiki Wikipedia-Artikel Das Windows-System verwendet seinen proprietären Betriebssystem-Bootloader, der als bekannt ist. Windows Boot Manager (BOOTMGR) Firmware ist nicht länger ein Stück Code. Es ist eine geworden, und aktuelle Trends tragen nur dazu bei. Wir können , und viele andere interessante Anwendungen darauf ausführen. kleines, komplexes riesige Menge an komplexem Code Doom Twitter Das Verständnis der Gesamtarchitektur hilft Ihnen dabei, diese Komponenten gedanklich zu organisieren. Indem Sie das Design vorhandener Firmware untersuchen, erhalten Sie Einblick in den faszinierenden Prozess, der sich jedes Mal entfaltet, wenn ein Computer eingeschaltet wird. Diese Top-Down-Perspektive verdeutlicht nicht nur die Rolle jedes Teils, sondern unterstreicht auch die anspruchsvolle und sich weiterentwickelnde Natur moderner Firmware-Systeme. Ressourcen UEFI-Spezifikation Version 2.10 UEFI-Plattform-Initialisierungsspezifikation Version 1.8 (Errata A) EDK II-Dokumentation Slim Bootloader-Projektdokumentation UEFI-Boot: Wie funktioniert das eigentlich? Grundlegendes zum Booten moderner UEFI-basierter Plattformen Anatomie der UEFI-Boot-Sequenz auf dem Intel Galileo Sehr einfacher Hinweis zu den „Pfaden“ von Festplattengeräten in einigen gängigen Architekturen. So booten Computer