UEFI-Anforderungen für Windows-Editionen auf SoC-Plattformen

In diesem Artikel werden UEFI-Anforderungen beschrieben, die für Windows 10 für Desktopeditionen (Home, Pro, Enterprise und Education) und Windows 10 Mobile gelten. Weitere Anforderungen, die nur für Windows 10 Mobile gelten, finden Sie unter UEFI-Anforderungen für Windows 10 Mobile.

Zusammenfassung der Anforderungen

In der folgenden Tabelle sind alle aktuellen Anforderungen für die UEFI-Konformität aufgeführt, wie in der UEFI-Spezifikation definiert (Abschnitt 2.6 der UEFI 2.3.1-Spezifikation). In dieser Tabelle identifiziert der Begriff Explizite Windows-Anforderung jedes Protokoll oder jeden Dienst, der direkt von einer Windows-Komponente aufgerufen wird. Obwohl nur diese Dienste explizit von Windows verwendet werden, können andere aufgeführte Dienste und Protokolle implizit oder explizit von einer Kernfirmwareimplementierung, EFI-Gerätetreibern oder von Entwicklungs- und Bereitstellungstoolketten erforderlich sein.

Microsoft begrüßt Feedback und Kommentare von Implementierern zu diesen Anforderungen. Für alle UEFI-Complianceanforderungen, die weder vom Betriebssystem noch von der Firmware verlangt werden, ist es unser Ziel, UEFI.org zu bearbeiten, um diese Complianceanforderungen für diese Geräteklasse zu lockern.

Weitere Informationen zu bestimmten Anforderungen finden Sie in den Abschnitten nach der Tabelle.

Anforderung	Abschnitt zur UEFI-Spezifikation	Hinweise
EFI-Systemtabelle	4.3	Explizite Windows-Anforderung
EFI-Startdienste	6.0
Ereignis-, Zeitgeber- und Aufgabendienste	6.1
Speicherdienste	6.2	Explizite Windows-Anforderung"
Protokollhandlerdienste	6.3	Explizite Windows-Anforderung
Imagedienste	6.4	Explizite Windows-Anforderung
Verschiedene Dienste	6,5	Explizite Windows-Anforderung
EFI-Laufzeitdienste	7.0
Zeitdienste	7.3	Explizite Windows-Anforderung
Variable Dienste	7.2	Explizite Windows-Anforderung
Verschiedene Dienste	7,5	Explizite Windows-Anforderung
Erforderliche UEFI-Protokolle
EFI-Geladenes Bildprotokoll	8.1
EFI geladene Image-Gerätepfadprotokoll	8,2
EFI-Gerätepfadprotokoll	9.2	Explizite Windows-Anforderung
EFI Device Path Utilities Protocol	9.5
EFI-Dekomprimierungsprotokoll	18.5
EBC-Interpreterprotokoll	20.11
Bedingt erforderliche UEFI-Protokolle
EFI-Protokoll für einfache Texteingabe	11,3	Explizite Windows-Anforderung
EFI–Ex-Protokoll für einfache Texteingabe	11.2
EFI-Ausgabeprotokoll für einfachen Text	11.4
EFI-Grafikausgabeprotokoll	11.9	Explizite Windows-Anforderung
EFI EDID- ermitteltes Protokoll	11.9.1
EFI EDID Active Protocol	11.9.1
EFI-Block-E/A-Protokoll	12,8	Explizite Windows-Anforderung
EFI-Datenträger-E/A-Protokoll	12.7
Einfaches EFI-Dateisystemprotokoll	12,4
EFI Unicode-Sortierungsprotokoll	12.10
Einfaches EFI-Netzwerkprotokoll	21,1
EFI PXE-Basiscodeprotokoll	21,3
EFI-Startintegritätsdiensteprotokoll	21,5
Serielles EFI-E/A-Protokoll	11,8
UEFI Arm-Bindung	2.3.5	Explizite Windows-Anforderung
Sicherheitsanforderungen
Sicherer Start	27.0	Explizite Windows-Anforderung
Start-Manager-Anforderungen	3.1, 3.3	Explizite Windows-Anforderung

EFI-Systemtabellenanforderungen

Die EFI-Systemtabelle muss der Standarddefinition auf der implementierten Revisionsebene entsprechen. Die Konfigurationstabelle, auf die die EFI-Systemtabelle verweist, muss die beiden GUIDs und die zugehörigen Zeiger enthalten, die in der folgenden Tabelle beschrieben sind.

GUID	Beschreibung
EFI_ACPI_Table GUID	Diese GUID muss auf den ACPI-Stammsystembeschreibungszeiger (RSDP) für die Plattform verweisen.
SMBIOS_Table GUID	Diese GUID muss auf die SMBIOS-Einstiegspunktstruktur verweisen. Windows erfordert die SMBIOS-Spezifikation auf der Revisionsebene 2.4 oder höher. Die Abschnitte 3.2, "Erforderliche Strukturen und Daten" und 4"Konformitätsrichtlinien" sind erforderlich. Ein Windows SMBIOS-Kompatibilitätstest ist verfügbar.

Anforderungen an EFI-Startdienste

In der folgenden Tabelle sind die Anforderungen für EFI-Startdienste für Windows aufgeführt.

EFI-Startdienst	Anforderung
Speicherdienste	Windows benötigt alle Speicherdienste.
Protokollhandlerdienste	Windows erfordert die folgenden Protokollhandlerdienste: OpenProtocol() CloseProtocol() LocateDevicePath() LocateHandle()
Imagedienste	Windows benötigt die folgenden Imagedienste: ExitBootServices()
Verschiedene Startdienste	Windows benötigt die folgenden verschiedenen Startdienste: Stall() Hinweis: Die Stall()-Implementierung ist erforderlich, um einen deterministischen (wiederholbaren) Fehler zu haben, sodass fehlerkorrektur oder -abbruch zuverlässig durchgeführt werden kann.

Anforderungen an EFI-Laufzeitdienste

In der folgenden Tabelle sind die Anforderungen der EFI-Laufzeitdienste für Windows aufgeführt.

EFI-Laufzeitdienst	Anforderung
Zeitdienste	Windows benötigt die folgenden Zeitdienste: GetTime() SetTime() Hinweis: Zeitdienste werden nur während des Startvorgangs (vor ExitBootServices()) für den Zugriff auf Plattformhardware zur Tageszeit aufgerufen.
Variable Dienste	Alle UEFI-Variablendienste sind für die Verwaltung mehrerer Startgeräte und Sicherheitsvariablen auf der Zielklasse von Systemen erforderlich.
Verschiedene Laufzeitdienste	Windows benötigt die folgenden verschiedenen Laufzeitdienste: ResetSystem() Hinweis: Die ResetSystem()-Implementierung muss sowohl Die Optionen zum Zurücksetzen als auch zum Herunterfahren unterstützen.

Protokollanforderungen

In der folgenden Tabelle werden die UEFI-Protokolle beschrieben, die von Windows zum Ausführen bestimmter Funktionen während des Startvorgangs erforderlich sind.

Protocol	Anforderung
Grafikausgabeprotokoll	Windows erfordert das Graphics Output Protocol (GOP). Spezifische Framepufferanforderungen sind: Für integrierte Displays müssen HorizontalResolution und VerticalResoluton die native Auflösung des Bereichs sein. Für externe Displays müssen HorizontalResolution und VerticalResoluton die native Auflösung des Displays sein, oder, wenn dies nicht unterstützt wird, die höchsten Werte, die sowohl von der Grafikkarte als auch vom verbundenen Display unterstützt werden. PixelsPerScanLine muss gleich HorizontalResolution sein. PixelFormat muss PixelBlueGreenRedReserved8BitPerColor sein. Ein physischer Framepuffer ist erforderlich. PixelBltOnly wird nicht unterstützt. Wenn die Ausführung an eine UEFI-Startanwendung übergeben wird, dürfen der Firmware-Start-Manager und die Firmware den Framepuffer nicht zu irgendeinem Zweck verwenden. Der Framepuffer muss weiterhin gescannt werden, nachdem die Startdienste beendet wurden.
Ausgabe der alternativen Anzeige	Die UEFI-Firmware muss das Starten mithilfe eines beliebigen Anzeigeconnectors unterstützen, der von der Hardware unterstützt wird. Wenn ein interner Bereich angeschlossen und sichtbar ist, muss das interne Panel verwendet werden. Alle Ausgaben mit physisch verbundenen Displays müssen den Startbildschirm anzeigen. Bei verbundenen Displays muss die UEFI-Firmware folgendes ausführen: Initialisieren Sie die Ausgabe mit dem einheitlichen Modus der Anzeige, wenn die native Auflösung bestimmt werden kann. Wenn ein systemeigener Modus nicht möglich ist, muss er mit dem höchsten kompatiblen Modus initialisiert werden. Wenn die Anzeigefunktionen nicht bestimmt werden können, muss die verbundene Anzeige in einem Modus initialisiert werden, der bekannt ist, dass er mit so vielen Monitoren wie möglich kompatibel ist (in der Regel 640x480 oder 1024x768, bei 60 Hz).
Eingabe zur Startzeit	Das EFI Simple Text Input Protocol ist erforderlich, um Startoptionen oder andere Menüauswahlen auf Systemen zu treffen, die über integrierte Tastaturen oder angeschlossene Tastaturen verfügen. Für Systeme ohne Tastatur werden drei Tasten in der Startumgebung empfohlen: Starttaste Schaltfläche "Lauter" Schaltfläche "Leiser" Tastendrucke sollten über das EFI Simple Text Input Protocol gemeldet werden, indem sie den folgenden Tastaturtasten zugeordnet werden: WINDOWS-TASTE NACH-OBEN-TASTE NACH-UNTEN-TASTE
Lokaler Speicherstart	Windows erfordert die Unterstützung des Block-E/A-Protokolls und des Gerätepfadprotokolls für die Speicherlösung, die die EFI-Systempartition und die Windows-Betriebssystempartition enthält. Für das Starten aus Flashspeicher, der Verschleißausgleich oder eine andere Flash-Verwaltung erfordert, muss dies in der Firmware (nicht in einer UEFI-Anwendung) implementiert werden.

Sicherheitsanforderungen

Windows hat Sicherheitsanforderungen in den Bereichen Sicherer Start, gemessener Start, Kryptografie und Datenschutz. Diese Anforderungen finden Sie in der folgenden Tabelle. Darüber hinaus werden für die Bereiche, in denen SoC-Hardware die Einhaltung des bestehenden Standards verhindert (TPM, RTC usw.), zusätzliche Anforderungen entwickelt. Diese werden am Ende der Tabelle beschrieben.

Bereich	Anforderung
Allgemein	Anforderung 1: OBLIGATORISCH. Die Plattform muss allen in diesem Abschnitt genannten Anforderungen entsprechen. Anforderung 2: OBLIGATORISCH. Plattformen müssen UEFI-Klasse 3 sein, ohne dass das Kompatibilitätsunterstützungsmodul installiert oder installiert werden kann. BIOS-Emulation und Legacy-PC/AT-Start müssen deaktiviert sein.
Sicherer UEFI-Start	Anforderung 3: OBLIGATORISCH. Sicherer Start gemäß Definition in UEFI v2.3.1 Abschnitt 27 muss aktiviert und mit einer Signaturdatenbank (EFI_IMAGE_SECURITY_DATABASE) ausgeliefert werden, die erforderlich ist, um den Computer sicher im Voraus zu starten. Der anfängliche Inhalt der Signaturdatenbank wird vom OEM basierend auf den erforderlichen UEFI-Treibern von Drittanbietern, den Wiederherstellungsanforderungen und dem auf dem Computer installierten Betriebssystem-Startladeprogramm bestimmt, aber es muss eine von Microsoft bereitgestellte EFI_CERT_X509 Signatur enthalten sein. Es dürfen keine zusätzlichen Unterschriften vorhanden sein. Anforderung 4: OBLIGATORISCH. Das Vorhandensein der UEFI-Datenbank "verbotene" Signatur (EFI_IMAGE_SECURITY_DATABASE1) ist erforderlich. Anforderung 5: OBLIGATORISCH. Ein von Microsoft bereitgestellter UEFI KEK muss in die UEFI KEK-Datenbank aufgenommen werden. Es dürfen keine zusätzlichen KEKs vorhanden sein. Microsoft stellt den KEK in Form einer EFI_CERT_X509 Signatur bereit. Anforderung 6: OBLIGATORISCH. EinPK-Pubschlüssel muss vorhanden sein und im Firmwareblitz gespeichert werden. Hinweis: Da PKpriv (das Private Key-Pendant zu PKpub) die Richtlinie für den sicheren Start auf allen Geräten steuert, die mit PKpub bereitgestellt werden, müssen deren Schutz und Verwendung streng geschützt werden. Anforderung 7: OBLIGATORISCH. Die anfänglichen Signaturdatenbanken werden im Firmware-Flash gespeichert und dürfen nur mit einem OEM-signierten Firmwareupdate oder durch UEFI-authentifizierte Variablenschreibvorgänge aktualisiert werden. Anforderung 8: OBLIGATORISCH. Images im Startpfad, für die die Signaturüberprüfung fehlschlägt, dürfen nicht ausgeführt werden, und der Grund für den Fehler wird dem EFI_IMAGE_EXECUTION_TABLE hinzugefügt. Darüber hinaus wird in diesen Situationen empfohlen, dass der UEFI-Start-Manager die Wiederherstellung gemäß einer OEM-spezifischen Strategie initiiert. Anforderung 9: OBLIGATORISCH. Die Außerkraftsetzung physisch vorhandener Benutzer darf für UEFI-Images, bei denen die Signaturüberprüfung fehlschlägt, nicht zulässig sein. Anforderung 10: OPTIONAL. Ein OEM kann die Möglichkeit implementieren, dass ein physisch vorhandener Benutzer den sicheren Start entweder mit Zugriff auf diePK-Priv oder mit physischer Anwesenheit über die Firmwareeinrichtung deaktivieren kann. Der Zugriff auf die Firmwareeinrichtung kann durch plattformspezifische Mittel (Administratorkennwort, intelligente Karte, statische Konfiguration usw.) geschützt werden. Anforderung 11: OBLIGATORISCH, wenn Anforderung 10 implementiert ist. Wenn Sicherer Start deaktiviert ist, kann nicht auf alle vorhandenen UEFI-Variablen zugegriffen werden. Anforderung 12: OPTIONAL. Ein OEM kann die Möglichkeit implementieren, dass ein physisch vorhandener Benutzer im Firmwaresetup zwischen zwei Modi für den sicheren Start auswählen kann: "Custom" und "Standard". Der benutzerdefinierte Modus ermöglicht mehr Flexibilität, wie im Folgenden angegeben. Anforderung 13: OBLIGATORISCH, wenn Anforderung 12 implementiert ist. Es muss möglich sein, einen deaktivierten sicheren Start im benutzerdefinierten Modus erneut zu aktivieren, indem eine besitzerspezifische PK festgelegt wird. Die Verwaltung erfolgt gemäß Abschnitt 27.5 der UEFI-Spezifikation v2.3.1: Firmware/Os Key Exchange. Im benutzerdefinierten Modus kann der Gerätebesitzer seine Auswahl an Signaturen in den Signaturdatenbanken festlegen. Anforderung 14: OBLIGATORISCH, wenn Anforderung 12 implementiert wird. Die Firmwareeinrichtung muss angeben, ob der sichere Start aktiviert ist und ob er im Standardmodus oder im benutzerdefinierten Modus betrieben wird. Das Firmwaresetup muss eine Option für die Rückkehr von "Benutzerdefiniert" in den Standardmodus bieten. Anforderung 15: OBLIGATORISCH. Wenn die Firmwareeinstellungen auf die Werkseinstellungen zurückgesetzt werden, werden alle benutzerdefinierten geschützten Variablen gelöscht, und der ursprünglichePK-Pub muss zusammen mit den ursprünglichen Signaturdatenbanken, die vom Hersteller bereitgestellt wurden, wiederhergestellt werden. Anforderung 16: OBLIGATORISCH. Die Fahrersignatur muss die Authenticode-Option (WIN_CERT_TYPE_PKCS_SIGNED_DATA) verwenden. Anforderung 17: OBLIGATORISCH. Unterstützung für die EFI_IMAGE_EXECUTION_INFO_TABLE (d. a. Erstellung und Speicherung von Informationen zu Images, die während des Startvorgangs gestartet oder nicht gestartet wurden). Anforderung 18: OBLIGATORISCH. Unterstützung von GetVariable() für die EFI_IMAGE_SECURITY_DATABASE (sowohl autorisierte als auch unzulässige Signaturdatenbank). Anforderung 19: OBLIGATORISCH. Unterstützung von SetVariable() für die EFI_IMAGE_SECURITY_DATABASE (sowohl autorisierte als auch unzulässige Signaturdatenbank) unter Verwendung des Microsoft KEK für die Authentifizierung. Anforderung 20: OBLIGATORISCH. EFI_HASH_SERVICE_BINDING_PROTOCOL: Dienstunterstützung: CreateChild(), DestroyChild(). Anforderung 21: OBLIGATORISCH. EFI_HASH_PROTOCOL. Dienstunterstützung: Hash(). Unterstützung für die Hashalgorithmen SHA_1 und SHA-256. Muss das Übergeben einer Nachricht unterstützen, die mindestens 10 MB lang ist.
UEFI– gemessener Start	Die folgenden Anforderungen bedeuten nicht, dass eine TCG-TPM-Implementierung erforderlich ist. sie impliziert jedoch die Notwendigkeit einer gleichwertigen Funktionalität für die betroffenen Bereiche. Die Plattformunterstützung kann durch eine Firmwareimplementierung eines TPM bereitgestellt werden, das in der sicheren Ausführungsumgebung ausgeführt wird, wobei die Schichtung auf der Kryptografiebeschleunigungs-Engine basiert und der isolierte Speicher genutzt wird. Microsoft kann möglicherweise Referenzsoftware für eine solche TPM-Implementierung zur Verwendung durch den Anbieter bereitstellen. Dies ist Gegenstand weiterer Diskussionen. Anforderung 22: OBLIGATORISCH. Die Plattform muss dem EFI-Protokoll entsprechen, das im EFI-Protokoll der UEFI Trusted Execution Environment angegeben ist. Anforderung 23: OBLIGATORISCH. Die Plattform muss der TCG EFI-Plattformspezifikation mit folgenden Ergänzungen entsprechen: Auf Plattformen, die die im TrEE EFI-Protokoll definierte Schnittstelle unterstützen, muss der Digest von PKpub auf TPM PCR[03] als EV_EFI_VARIABLE_CONFIG-Ereignis erweitert werden. Der Digest des Inhalts der autorisierten Signaturdatenbank (siehe Abschnitt 27.8 der UEFI-Spezifikation v2.3.1) muss im gemessenen Start als EV_EFI_VARIABLE_CONFIG-Ereignis erweitert werden. Der Erweiterungsvorgang muss auf TPM PCR[03] erfolgen. Ein UEFI-Client muss die Liste der Zertifikate mithilfe der variablen EFI_IMAGE_SECURITY_DATABASE lesen und analysieren und den Digest anhand des erweiterten Werts überprüfen können. TCG_PCR_EVENT Digestwerte müssen SHA-256 und nicht SHA-1 sein. Anforderung 24: OBLIGATORISCH. Die Plattform muss das in der TCG Platform Reset Attack Mitigation Specification definierte MemoryOverwriteRequestControl implementieren.
Kryptografie	Anforderung 25: OBLIGATORISCH. Die Plattform stellt die EFI_HASH_PROTOCOL (UEFI v2.3.1 Abschnitt 27.4) für die Auslagerung kryptografischer Hashvorgänge bereit. SHA-256 muss unterstützt werden. Anforderung 26: OBLIGATORISCH. Die Plattform muss die von Microsoft definierten EFI_RNG_PROTOCOL für das Lesen von Entropie vor dem Betriebssystem unterstützen.
Schutz von Daten	Anforderung 27: OBLIGATORISCH. Die Plattform muss EFI-Variablen mit einer beliebigen Kombination der folgenden UEFI-Variablenattribute unterstützen: EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Weitere Sicherheitsanforderungen	Die folgenden zusätzlichen Anforderungen sind für Windows auf SoC-Plattformen erforderlich. Microsoft hat das Protokoll zum Sammeln von Entropie von einer UEFI-Plattform definiert. Dieses Protokoll ist zwar keine UEFI-Anforderung, aber für Windows auf SoC-Plattformen ist dieses Protokoll erforderlich. Weitere Informationen zu diesem Protokoll finden Sie unter UEFI-Entropiesammlungsprotokoll. UEFI-Signaturdatenbank Updates. In Abschnitt 27 von UEFI 2.3.1 wurde ein neuer Mechanismus zum Aktualisieren authentifizierter Variablen eingeführt. Dieser Mechanismus ist für Windows erforderlich. Vertrauenswürdige Ausführungsumgebung. Microsoft hat ein EFI-Protokoll für die Interaktion mit einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TrEE) entwickelt, ähnlich der Funktionalität einer Teilmenge eines Trusted Computing Group (TCG) Trusted Platform Module (TPM). Das EFI-Protokoll nutzt in hohem Maße das "TCG EFI-Protokoll", Version 1.2 Revision 1.00, 9. Juni 2006, von der Trusted Computing Group. Ausführliche Informationen finden Sie unter EFI-Protokoll für UEFI Trusted Execution Environment( UEFI Trusted Execution Environment).

Anforderungen an den Firmwarestart-Manager

Der Firmwarestart-Manager muss das in Abschnitt 3.3 der Spezifikation definierte Standardstartverhalten unterstützen. Darüber hinaus sind für die Unterstützung von Multistarts global definierte Variablen und die Anforderungen des Start-Managers gemäß Abschnitt 3.1 der Spezifikation erforderlich.

UEFI Arm-Bindungsanforderungen

Die UEFI-Arm-Bindung enthält spezifische Anforderungen für die Arm-Plattform, die für die UEFI-Spezifikation erforderlich ist. Windows erfordert alles in der Arm-Bindung, das für ARMv7 gilt. Da Windows nichts vor ARMv7 unterstützt, sind Anforderungen in der Bindung, die für ARMv6k und niedriger spezifisch sind, optional.

Die Bindung gibt beispielsweise an, wie die MMU konfiguriert werden soll und wie physischer Arbeitsspeicher zugeordnet werden soll. Die Bindung gibt auch an, dass Aufrufe von UEFI-Protokollen und -Diensten nur in arm ISA erfolgen sollen, was bedeutet, dass Software, die in Thumb2 oder Thumb ausgeführt wird, vor dem Aufrufen von UEFI-Funktionen wieder in den Arm-Modus wechseln muss.

UEFI Arm-Multiprozessorstartanforderungen

Microsoft hat ein Protokoll zum Starten mehrerer Arm-Kerne auf einer UEFI-Plattform mit mehreren Prozessoren entwickelt. Dieses Protokoll ist für Windows auf Arm-Plattformen erforderlich, die die Power State Coordination Interface (PSCI) nicht unterstützen. Plattformen, die PSCI unterstützen, dürfen dieses Protokoll nicht verwenden. Weitere Informationen zu diesem Protokoll finden Sie im Dokument Multiprozessorstart auf armbasierten UEFI-Plattformen auf der ACPI-Komponentenarchitektur (ACPICA).

Anforderungen an die Plattformeinrichtung

Die Firmware ist dafür verantwortlich, die Systemhardware in einen klar definierten Zustand zu versetzen, bevor sie an das Betriebssystemladeprogramm übergeben wird. In der folgenden Tabelle werden die zugehörigen Anforderungen für die Plattformeinrichtung definiert.

Anforderung	BESCHREIBUNG
Startpfad	Die Firmware muss die Plattform so initialisieren, dass Windows über UEFI auf das Startgerät zugreifen und den Kernel laden kann. Jedes Gerät, das an der Hierarchie beteiligt ist, um vom Startgerät zu lesen, muss unter Berücksichtigung von Leistungs- und Leistungsaspekten mit angemessener Geschwindigkeit getaktet und mit Strom versorgt werden. Der Basisprozessorkern selbst sollte ebenfalls getaktet und mit einer angemessenen Geschwindigkeit mit Strom versorgt werden, damit das System rechtzeitig starten kann, ohne den Akku zu entleeren.
Kernsystemressourcen	Die Kernsystemressourcen, die über ACPI-Tabellen für das Betriebssystem verfügbar gemacht werden, müssen eingeschaltet und getaktet werden. Zu den Kernsystemressourcen gehören Interruptcontroller, Timer und DMA-Controller, die vom Betriebssystem verwaltet werden müssen. Darüber hinaus müssen Interrupts durch den Aufruf von ExitBootServices() maskiert werden, bis der zugehörige Gerätetreiber im Betriebssystem die Maskierung von Interrupts auf dem Gerät entschlüsselt und wieder aktiviert. Wenn Interrupts während des Startdiensts aktiviert werden, wird davon ausgegangen, dass sie von der Firmware verwaltet werden.
Debuggen	Windows unterstützt das Debuggen über USB 3 Host (XHCI), USB 2 Host (EHCI)1, IEEE 1394, serielle und USB-Funktionsschnittstellen (sowie PCI-Ethernet-Adapter). Mindestens eine davon muss vor der Betriebssystemübergabe von der Firmware mit Strom versorgt, getaktet und initialisiert werden. Unabhängig davon, welche Option bereitgestellt wird, muss er über einen verfügbaren Port für Debuggingzwecke verfügen, und der Controller muss arbeitsspeicherseitig zugeordnet oder über einen dedizierten (nicht freigegebenen) Peripheriebus verbunden sein.
Andere Anforderungen an die Plattformeinrichtung	Alle Pin-Multiplexing- und Padkonfigurationen müssen in der Firmware abgeschlossen werden, bevor die Steuerung an das Betriebssystemladeprogramm übergeben wird.

Installationsanforderungen

Windows erfordert, dass sich die Betriebssystempartition in einer GPT-Partitionierungsspeicherlösung befindet. Der partitionierte MBR-Speicher kann als Datenspeicher verwendet werden. Wie in der UEFI-Spezifikation definiert, erfordert eine UEFI-Plattform eine dedizierte Systempartition. Windows erfordert diese dedizierte Systempartition, die als EFI-Systempartition (ESP) bezeichnet wird.

Hardwaresicherheitstestschnittstelle (Hardware Security Test Interface, HSTI)

Die Plattform muss die Hardwaresicherheitstestschnittstelle implementieren, und die Plattform muss Dokumentation und Tools freigeben, wie in der Hardwaresicherheitstestfähigkeitsspezifikation angegeben.

Verwandte Artikel

UEFI-Mindestanforderungen für Windows auf SoC-Plattformen

UEFI-Anforderungen für Windows 10 Mobile

UEFI-Anforderungen für USB-Flashunterstützung