UEFI-vereisten voor Windows-edities op SoC-platforms
In dit artikel worden UEFI-vereisten beschreven die van toepassing zijn op Windows 10 voor desktopversies (Home, Pro, Enterprise en Education).
Overzicht van vereisten
De volgende tabel bevat alle huidige vereisten voor UEFI-naleving, zoals gedefinieerd in de UEFI-specificatie (sectie 2.6 van de UEFI 2.3.1-specificatie). In deze tabel identificeert de term Expliciete Windows-vereiste elk protocol of elke service identificeert die rechtstreeks wordt aangeroepen door een Windows-onderdeel. Hoewel alleen deze services expliciet door Windows worden gebruikt, kunnen andere vermelde services en protocollen impliciet of expliciet vereist zijn voor een kernfirmware-implementatie, EFI-apparaatstuurprogramma's of door hulpprogrammaketens voor ontwikkeling en implementatie.
Microsoft verwelkomt feedback en opmerkingen van implementatoren over deze set vereisten. Voor alle UEFI-nalevingsvereisten die niet verplicht zijn gesteld door het besturingssysteem of de firmware, is het onze bedoeling om via UEFI.org deze vereisten voor naleving te versoepelen voor dit type apparaat.
Zie de secties na de tabel voor meer informatie over specifieke vereisten.
Eis | UEFI-specificatiesectie | Notities |
---|---|---|
EFI-systeemtabel | 4.3 | Expliciete Windows-vereiste |
EFI-bootservices | 6.0 | |
Gebeurtenis-, timer- en taakservices | 6.1 | |
Geheugenservices | 6.2 | Specifieke Windows-vereiste |
Protocolafhandeldiensten | 6.3 | Expliciete Windows-vereiste |
Installatiekopieënservices | 6.4 | Expliciete Windows-vereiste |
Diverse services | 6.5 | Expliciete Windowsvereiste |
EFI Runtime-services | 7.0 | |
Tijdservices | 7.3 | Expliciete Windows-vereiste |
Variabele services | 7.2 | Expliciete Windows-vereiste |
Diverse services | 7.5 | Expliciete Windows vereiste |
vereiste UEFI-protocollen | ||
EFI geladen afbeelding protocol | 8.1 | |
EFI geladen afbeeldingsapparaatpadprotocol | 8.2 | |
EFI-apparaatpad-protocol | 9.2 | Expliciete Windows-vereiste |
Protocol voor EFI-apparaatpadhulpprogramma's | 9.5 | |
EFI-decompressieprotocol | 18,5 | |
EBC-interpreterprotocol | 20.11 | |
voorwaardelijk vereiste UEFI-protocollen | ||
EFI simple text input protocol | 11.3 | Expliciete Windows-vereiste |
EFI eenvoudige tekstinvoer EX-protocol | 11.2 | |
EFI eenvoudige tekstuitvoerprotocol | 11.4 | |
Uitvoerprotocol voor EFI-afbeeldingen | 11.9 | Expliciete Windows vereiste |
EFI EDID ontdekt protocol | 11.9.1 | |
Actief EFI EDID-protocol | 11.9.1 | |
I/O-protocol blokkeren voor EFI | 12.8 | Expliciete Windows-vereiste |
IO-protocol van EFI-schijf | 12.7 | |
EFI eenvoudig bestandssysteemprotocol | 12.4 | |
EFI Unicode-sorteringsprotocol | 12.10 | |
Eenvoudig EFI-netwerkprotocol | 21.1 | |
EFI PXE-basiscodeprotocol | 21.3 | |
Protocol voor EFI-opstartintegriteitsservices | 21.5 | |
EFI-seriële IO-protocol | 11.8 | |
UEFI Arm binding | 2.3.5 | Expliciete Windows-vereiste |
beveiligingsvereisten | ||
Beveiligd opstarten | 27.0 | Expliciete Windows-vereiste |
Vereisten voor opstartbeheer | 3.1, 3.3 | Expliciete Windows-vereiste |
Vereisten voor EFI-systeemtabellen
De EFI-systeemtabel moet voldoen aan de standaarddefinitie op het geïmplementeerde revisieniveau. De configuratietabel waarnaar wordt verwezen door de EFI-systeemtabel moet de twee GUID's en de bijbehorende aanwijzers bevatten die in de volgende tabel worden beschreven.
GUID | Beschrijving |
---|---|
EFI_ACPI_Table GUID | Deze GUID moet verwijzen naar de ACPI Root System Description Pointer (RSDP) voor het platform. |
SMBIOS_Table GUID | Deze GUID moet verwijzen naar de SMBIOS-toegangspuntstructuur. Voor Windows is SMBIOS-specificatie vereist, op revisieniveau 2.4 of hoger. Sectie 3.2, "Vereiste structuren en gegevens" en 4, "Richtlijnen voor naleving", zijn vereist. Er is een Windows SMBIOS-compatibiliteitstest beschikbaar. |
Vereisten voor EFI-opstartservices
De volgende tabel bevat de vereisten voor EFI-opstartservices voor Windows.
EFI-opstartservice | Vereiste |
---|---|
Geheugenservices | Windows vereist alle geheugendiensten. |
Protocolhandlerdiensten | Voor Windows zijn de volgende protocolhandlerservices vereist: OpenProtocol() SluitProtocol() LocateDevicePath() LocateHandle() |
Installatiekopieënservices | Windows vereist de volgende imageservices: ExitBootServices() |
Diverse opstartservices | Voor Windows zijn de volgende diverse opstartservices vereist: Stall() Opmerking: De implementatie van Stall() is vereist om een deterministische (herhaalbare) fout te hebben, zodat foutcorrectie of annulering betrouwbaar kan worden uitgevoerd. |
Vereisten voor EFI-runtime services
De volgende tabel bevat de vereisten voor EFI-runtimeservices voor Windows.
EFI-runtimedienst | Eis |
---|---|
Tijdservices | Voor Windows zijn de volgende tijdservices vereist: GetTime() SetTime() Opmerking: Tijdsdiensten worden alleen tijdens het opstarten aangeroepen (vóór ExitBootServices()) voor toegang tot de tijdweergavehardware van het platform. |
Variabele services | Alle UEFI Variable Services zijn vereist voor het beheren van meerdere opstartapparaten en beveiligingsvariabelen op de doelklasse van systemen. |
Diverse runtimediensten | Voor Windows zijn de volgende diverse runtimeservices vereist: ResetSystem() Opmerking: De resetsystem() implementatie moet zowel reset- als afsluitopties ondersteunen. |
Protocolvereisten
In de volgende tabel worden de UEFI-protocollen beschreven die door Windows zijn vereist voor het uitvoeren van specifieke functies tijdens het opstarten.
Protocol | Eis |
---|---|
Grafisch uitvoerprotocol | Windows vereist het Graphics Output Protocol (GOP). Specifieke vereisten voor framebuffers zijn: Voor geïntegreerde schermen moet HorizontalResolution en VerticalResolution de systeemeigen resolutie van het paneel zijn. Voor externe beeldschermen moet HorizontalResolution- en VerticalResolution- de systeemeigen resolutie van het beeldscherm zijn of, als dit niet wordt ondersteund, de hoogste waarden die worden ondersteund door zowel de videoadapter als het aangesloten beeldscherm. PixelsPerScanLine- moet gelijk zijn aan HorizontalResolution-. PixelFormat- moet PixelBlueGreenRedReserved8BitPerColorzijn. Er is een fysieke framebuffer vereist; PixelBltOnly- wordt niet ondersteund. Wanneer de uitvoering wordt overgedragen aan een UEFI-opstarttoepassing, mogen de firmware-opstartbeheer en firmware de framebuffer voor geen enkel doel gebruiken. De framebuffer moet nog steeds worden gescand nadat opstartservices zijn afgesloten. |
Alternatieve weergave-uitvoer | De UEFI-firmware moet ondersteuning bieden voor opstarten met behulp van een weergaveconnector die wordt ondersteund door de hardware. Als er een intern paneel is aangesloten en zichtbaar is, moet het interne paneel worden gebruikt. Alle uitvoer die fysiek verbonden is, moet het opstartscherm weergeven. Voor verbonden beeldschermen moet de UEFI-firmware: Initialiseer de uitvoer met de systeemeigen modus van de weergave, als de systeemeigen resolutie kan worden bepaald. Als een systeemeigen modus niet mogelijk is, moet deze worden geïnitialiseerd naar de hoogste compatibele modus. Als de weergavemogelijkheden niet kunnen worden bepaald, moet de aangesloten weergave worden geïnitialiseerd in een modus die bekend is dat deze compatibel is met zoveel mogelijk beeldschermen (meestal 640x480 of 1024x768, bij 60 Hz). |
Invoer tijdens het opstarten | Het EFI Simple Text Input Protocol is vereist voor het maken van opstartkeuzen of andere menuselecties op systemen met ingebouwde toetsenborden of gekoppelde toetsenborden. Voor toetsenbordloze systemen worden drie knoppen aanbevolen in de opstartomgeving: Startknop Volume omhoog-knop Volumeknop omlaag Knopindrukken moeten worden gerapporteerd via het EFI Simple Text Input Protocol door ze respectievelijk te koppelen aan de volgende toetsenbordtoetsen: Windows-toets Pijl-omhoog Pijl-omlaag-toets |
Lokale opslag opstarten | Windows vereist ondersteuning voor Blok I/O Protocol en Device Path Protocol voor de opslagoplossing die de EFI-systeempartitie en de Windows-besturingssysteempartitie bevat. Voor het opstarten vanuit flashopslag waarvoor slijtage leveling of ander flashbeheer is vereist, moet dit worden geïmplementeerd in de firmware (niet in een UEFI-toepassing). |
Beveiligingsvereisten
Windows heeft beveiligingsvereisten op het gebied van Beveiligd opstarten, Gemeten opstarten, Cryptografie en Gegevensbeveiliging. Deze vereisten worden beschreven in de volgende tabel. Daarnaast worden voor die gebieden waarin SoC-hardware naleving van de bestaande standaard (TPM, RTC, enzovoort) verhindert, aanvullende vereisten ontwikkeld. Deze worden aan het einde van de tabel beschreven.
Gebied | Eis |
---|---|
Algemeen |
|
Beveiligd opstarten met UEFI |
|
Met UEFI gemeten opstart | De volgende vereisten impliceren geen noodzaak voor een TCG TPM-implementatie; ze impliceren echter een behoefte aan gelijkwaardige functionaliteit voor de betrokken gebieden. De platformondersteuning kan worden geboden door een firmware-implementatie van een TPM die wordt uitgevoerd in de beveiligde uitvoeringsomgeving, gelaagd boven op de cryptografische versnellingsengine en gebruik te maken van de geïsoleerde opslag. Microsoft kan mogelijk referentiesoftware opgeven voor een dergelijke TPM-implementatie voor gebruik door de leverancier. Dit is onderhevig aan verdere discussies.
|
Cryptografie |
|
Gegevensbescherming |
|
Andere beveiligingsvereisten | De volgende aanvullende vereisten zijn vereist voor Windows op SoC-platforms.
|
Vereisten voor firmware-opstartbeheer
De firmware boot manager moet het standaard opstartgedrag ondersteunen dat is gedefinieerd in sectie 3.3 van de specificatie. Daarnaast zijn voor ondersteuning van multi-boot, wereldwijd gedefinieerde variabelen en de Boot Manager-vereisten van sectie 3.1 van de specificatie vereist.
Vereisten voor UEFI Arm-koppeling
De UEFI Arm Binding bevat vereisten die specifiek zijn voor het Arm-platform dat nodig is om compatibel te zijn met UEFI-specificaties. Windows vereist alles in de Arm-binding die van toepassing is op ARMv7. Omdat Windows geen ondersteuning biedt voor armv7, zijn vereisten in de binding die specifiek zijn voor ARMv6k en hieronder optioneel.
De binding geeft bijvoorbeeld aan hoe de MMU moet worden geconfigureerd en hoe fysiek geheugen moet worden toegewezen. De binding geeft ook aan dat aanroepen naar UEFI-protocollen en -services alleen moeten worden uitgevoerd in de Arm ISA, wat betekent dat software die wordt uitgevoerd in Thumb2 of Thumb, moet terugkeren naar de Arm-modus voordat UEFI-functies worden aangeroepen.
Opstartvereisten voor UEFI Arm multiprocessor
Microsoft heeft een protocol ontwikkeld voor het starten van meerdere Arm-kernen op een UEFI-platform met meerdere processoren. Dit protocol is vereist voor Windows op Arm-platforms die geen ondersteuning bieden voor de PSCI-(Power State Coordination Interface). Platforms die wel PSCI ondersteunen, mogen dit protocol niet gebruiken. Zie voor meer informatie over dit protocol het multiprocessor opstarten op UEFI Arm-platforms document op de ACPI Component Architecture (ACPICA)-website.
Vereisten voor platforminstellingen
De firmware is verantwoordelijk voor het brengen van de systeemhardware in een goed gedefinieerde staat voordat deze wordt overgedragen aan de OS-loader. In de volgende tabel worden de gerelateerde vereisten voor het instellen van het platform gedefinieerd.
Eis | Beschrijving |
---|---|
Opstartpad | De firmware moet het platform initialiseren tot het punt waar Windows toegang heeft tot het opstartapparaat via UEFI en de kernel kan laden. Elk apparaat dat in de hiërarchie is betrokken om te lezen vanaf het opstartapparaat, moet worden geklokt en aangedreven tegen een redelijke snelheid, gezien de prestaties en energieoverwegingen. De basisprocessorkern zelf moet ook met een redelijke snelheid worden geklokt en aangedreven, zodat het systeem tijdig kan opstarten zonder de batterij leeg te maken. |
Kernsysteemresources | De coresysteemresources die beschikbaar zijn voor het besturingssysteem via ACPI-tabellen, moeten worden ingeschakeld en geklokt. Kernsysteemresources omvatten Interrupt-controllers, Timers en DMA-controllers die moeten worden beheerd door het besturingssysteem. Bovendien moeten interrupts worden gemaskeerd door de aanroep naar ExitBootServices() totdat het bijbehorende apparaatstuurprogramma in het besturingssysteem ontmaskert en interrupts opnieuw inschakelt op het apparaat. Als interrupts zijn ingeschakeld tijdens opstartservices, wordt ervan uitgegaan dat de firmware deze beheert. |
Foutopsporing | Windows ondersteunt foutopsporing via USB 3 Host (XHCI) , USB 2 Host (EHCI)1, IEEE 1394, seriële en USB-functieinterfaces (evenals PCI-ethernetadapters). Ten minste één van deze moet worden bekrachtigd, geklokt en geïnitialiseerd door de firmware vóór de overdracht van het besturingssysteem. Welke optie ook wordt gekozen, het moet een blootgestelde poort hebben voor foutopsporing en de controller moet geheugengekoppeld zijn of verbonden zijn via een dedicated (niet-gezamenlijke) randapparatuurbus. |
Andere vereisten voor het instellen van het platform | Elke configuratie van pin-multiplexing en padconfiguratie moet in de firmware worden voltooid voordat de controle aan de OS-laadprogramma wordt overgedragen. |
Installatievereisten
Voor Windows is vereist dat de besturingssysteempartitie zich op een gpT-gepartitioneerde opslagoplossing bevindt. Gepartitioneerde MBR-opslag kan worden gebruikt als gegevensopslag. Zoals gedefinieerd in de UEFI-specificatie, vereist een UEFI-platform een toegewezen systeempartitie. Windows vereist deze toegewezen systeempartitie, aangeduid als de EFI-systeempartitie (ESP).
Hardware Security Test Interface (HSTI) vereiste
Het platform moet de Hardware Security Test Interface implementeren en het platform is vereist voor het delen van documentatie en hulpprogramma's zoals opgegeven in de Hardware Security Testability Specification.