Delen via


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
  • Vereiste 1: VERPLICHT. Het platform voldoet aan alle vereisten die in deze sectie zijn opgegeven.

  • Vereiste 2: VERPLICHT. Platformen zijn UEFI-klasse Drie zonder geïnstalleerde of installeerbare compatibiliteitsondersteuningsmodule. BIOS-emulatie en verouderde pc/AT-opstartbewerking moeten worden uitgeschakeld.

Beveiligd opstarten met UEFI
  • Vereiste 3: VERPLICHT. Beveiligd opstarten, zoals gedefinieerd in UEFI v2.3.1 sectie 27, moet ingeschakeld zijn en beschikken over een handtekeningdatabase (EFI_IMAGE_SECURITY_DATABASE) die noodzakelijk is om de machine veilig vooraf geconfigureerd op te starten. De oorspronkelijke inhoud van de handtekeningdatabase wordt bepaald door de OEM, op basis van de vereiste UEFI-stuurprogramma's van derden, herstelbehoeften en het opstartlaadprogramma van het besturingssysteem dat op de computer is geïnstalleerd, maar een door Microsoft geleverde EFI_CERT_X509 handtekening moet worden opgenomen. Er zijn geen aanvullende handtekeningen aanwezig.

  • Vereiste 4: VERPLICHT. Aanwezigheid van de UEFI-handtekeningdatabase (EFI_IMAGE_SECURITY_DATABASE1) is vereist.

  • Vereiste 5: VERPLICHT. Een door Microsoft geleverde UEFI KEK wordt opgenomen in de UEFI KEK-database. Er zijn geen extra KK's aanwezig. Microsoft biedt de KEK in de vorm van een EFI_CERT_X509 ondertekening.

  • Vereiste 6: VERPLICHT. Een PKpub sleutel moet aanwezig zijn en worden opgeslagen in firmware flash. Opmerking: omdat PKpriv- (de tegenhanger voor persoonlijke sleutels van PKpub) het beleid voor beveiligd opstarten beheert op alle apparaten die zijn ingericht met PKpub, moet de beveiliging en het gebruik ervan nauw worden bewaakt.

  • Vereiste 7: VERPLICHT. De eerste handtekeningdatabases worden opgeslagen in firmware flash en kunnen alleen worden bijgewerkt met een OEM-ondertekende firmware-update of via door UEFI geverifieerde variabele schrijven.

  • Vereiste 8: VERPLICHT. Installatiekopieën in het opstartpad waarvoor de handtekeningverificatie mislukt, mogen niet worden uitgevoerd en de reden voor de fout wordt toegevoegd aan de EFI_IMAGE_EXECUTION_TABLE. Verder is de aanbevolen aanpak in deze situaties dat de UEFI-opstartmanager herstel start volgens een OEM-specifieke strategie.

  • Vereiste 9: VERPLICHT. Fysiek aanwezige gebruikersomzeiling mag niet toegestaan worden voor UEFI-afbeeldingen die de handtekeningverificatie niet doorstaan.

  • Vereiste 10: Optioneel. Een OEM kan de mogelijkheid voor een fysiek aanwezige gebruiker implementeren om Beveiligd opstarten uit te schakelen met toegang tot de PK-priv of met fysieke aanwezigheid via de firmware-installatie. Toegang tot de firmware-installatie kan worden beveiligd met platformspecifieke middelen (beheerderswachtwoord, smartcard, statische configuratie, enzovoort)

  • Vereiste 11: VERPLICHT als vereiste 10 wordt geïmplementeerd. Als Beveiligd opstarten is uitgeschakeld, zijn alle bestaande UEFI-variabelen niet toegankelijk.

  • Voorwaarde 12: Optioneel. Een OEM kan de mogelijkheid voor een fysiek aanwezige gebruiker implementeren om te kiezen tussen twee veilige opstartmodi in de firmware-installatie: 'Aangepast' en 'Standaard'. Aangepaste modus biedt meer flexibiliteit, zoals is opgegeven in het volgende.

  • Vereiste 13: VERPLICHT als vereiste 12 wordt geïmplementeerd. Het moet mogelijk zijn om een uitgeschakelde Secure Boot opnieuw in te schakelen in de Aangepaste Modus door een eigenaar specifieke PKin te stellen. Het beheer gaat verder zoals gedefinieerd in sectie 27.5 van de UEFI-specificatie v2.3.1: Firmware/OS Key Exchange. In de aangepaste modus kan de eigenaar van het apparaat de keuze van handtekeningen instellen in de handtekeningdatabases.

  • Vereiste 14: VERPLICHT als vereiste 12 wordt geïmplementeerd. De firmware-installatie geeft aan of Beveiligd opstarten is ingeschakeld en of deze wordt uitgevoerd in de standaard- of aangepaste modus. De firmware-installatie biedt een optie om terug te keren van aangepaste naar standaardmodus.

  • Vereiste 15: VERPLICHT. Als de firmware-instellingen worden teruggezet op de fabrieksinstellingen, worden alle aangepaste beveiligde variabelen gewist en worden de oorspronkelijke PK-pub- samen met de oorspronkelijke, door de fabrikant ingerichte handtekeningdatabases opnieuw ingesteld.

  • Vereiste 16: VERPLICHT. Ondertekening van stuurprogramma's gebruikt de optie Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA).

  • Vereiste 17: VERPLICHT. Ondersteuning voor de EFI_IMAGE_EXECUTION_INFO_TABLE (dat wil zeggen, het maken en opslaan van informatie over afbeeldingen die tijdens het opstarten zijn gestart of niet zijn gestart).

  • Vereiste 18: VERPLICHT. Ondersteuning voor GetVariable() voor de EFI_IMAGE_SECURITY_DATABASE (zowel geautoriseerde als verboden handtekeningdatabase).

  • Vereiste 19: VERPLICHT. Ondersteuning voor SetVariable() voor de EFI_IMAGE_SECURITY_DATABASE (zowel geautoriseerde als verboden handtekeningdatabase), met behulp van de Microsoft KEK voor verificatie.

  • Vereiste 20: VERPLICHT. EFI_HASH_SERVICE_BINDING_PROTOCOL: Service-ondersteuning: CreateChild(), DestroyChild().

  • Vereiste 21: VERPLICHT. EFI_HASH_PROTOCOL. Serviceondersteuning: Hash(). Ondersteuning voor de SHA_1- en SHA-256-hashalgoritmen. Moet ondersteuning bieden voor het doorgeven van een bericht van ten minste 10 Mbytes.

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.

  • Vereiste 22: VERPLICHT. Het platform voldoet aan het EFI-protocol dat is opgegeven in de UEFI Trusted Execution Environment EFI Protocol.

  • Vereiste 23: VERPLICHT. Het platform voldoet aan de TCG EFI-platformspecificatie met de volgende toevoegingen:

    • Op platforms die de interface ondersteunen die is gedefinieerd in het TrEE EFI-protocol, wordt de digest van PKpub uitgebreid naar TPM PCR[03] als een EV_EFI_VARIABLE_CONFIG-gebeurtenis.

    • De samenvatting van de inhoud van de geautoriseerde handtekeningdatabase (zie sectie 27.8 van de UEFI-specificatie v2.3.1) lijst moet worden uitgebreid in de gemeten opstartbewerking als een EV_EFI_VARIABLE_CONFIG gebeurtenis. De uitbreidingsbewerking wordt uitgevoerd op TPM PCR[03].

    • Het is mogelijk dat een UEFI-client de lijst met certificaten leest en parseert met behulp van de EFI_IMAGE_SECURITY_DATABASE variabele en de samenvatting valideert op basis van de uitgebreide waarde.

    • TCG_PCR_EVENT samenvattingswaarden moeten SHA-256 zijn, niet SHA-1.

  • Vereiste 24: VERPLICHT. Het platform moet de MemoryOverwriteRequestControl, zoals gedefinieerd in de TCG Platform Reset Attack Mitigation Specification, implementeren.

Cryptografie
  • Vereiste 25: VERPLICHT. Het platform verstrekt de EFI_HASH_PROTOCOL (UEFI v2.3.1, sectie 27.4) voor offload van cryptografische hashbewerkingen. SHA-256 moet worden ondersteund.

  • Vereiste 26: VERPLICHT. Het platform ondersteunt de door Microsoft gedefinieerde EFI_RNG_PROTOCOL voor het lezen van entropie vóór het besturingssysteem.

Gegevensbescherming
  • Vereiste 27: VERPLICHT. Het platform moet EFI-variabelen ondersteunen met elke combinatie van de volgende UEFI-variabeleattributen ingesteld:

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS

Andere beveiligingsvereisten

De volgende aanvullende vereisten zijn vereist voor Windows op SoC-platforms.

  • Microsoft heeft een protocol gedefinieerd voor het verzamelen van entropie van een UEFI-platform. Hoewel er geen UEFI-vereiste is, is dit protocol vereist voor Windows op SoC-platforms. Zie UEFI-entropieprotocolvoor meer informatie over dit protocol.

  • Updates voor UEFI Signature Database. Er is een nieuw mechanisme voor het bijwerken van geverifieerde variabelen vastgesteld in sectie 27 van UEFI 2.3.1. Dit mechanisme is vereist voor Windows.

  • Vertrouwde uitvoeringsomgeving. Microsoft heeft een EFI-protocol ontwikkeld voor interactie met een Trusted Execution Environment (TrEE), vergelijkbaar met een subset van een Trusted Computing Group (TCG) Trusted Platform Module (TPM). Het EFI-protocol maakt in grote mate gebruik van het "TCG EFI Protocol," versie 1.2, revisie 1.00, op 9 juni 2006, door de Trusted Computing Group.

    Raadpleeg UEFI Trusted Execution Environment EFI Protocolvoor meer informatie.

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.

Minimale UEFI-vereisten voor Windows op SoC-platforms

UEFI-vereisten voor usb-flashing-ondersteuning