Requisiti UEFI per le edizioni di Windows nelle piattaforme SoC

Questo articolo descrive i requisiti UEFI che si applicano a Windows 10 per le edizioni desktop (Home, Pro, Enterprise e Education).

Riepilogo dei requisiti

La tabella seguente elenca tutti i requisiti correnti per la conformità UEFI, come definito nella specifica UEFI (sezione 2.6 della specifica UEFI 2.3.1). In questa tabella il termine requisito esplicito di Windows identifica qualsiasi protocollo o servizio chiamato direttamente da un componente di Windows. Anche se solo questi servizi vengono usati in modo esplicito da Windows, altri servizi e protocolli elencati possono essere implicitamente o esplicitamente richiesti da un'implementazione del firmware principale, driver di dispositivo EFI o da catene di strumenti di sviluppo e distribuzione.

Microsoft accoglie il feedback e i commenti degli implementatori su questo set di requisiti. Per tutti i requisiti di conformità UEFI che sono stati individuati come non richiesti dal sistema operativo o dal firmware, è nostra intenzione collaborare con UEFI.org per avere questi requisiti di conformità alleggeriti per questa classe di dispositivi.

Per altre informazioni sui requisiti specifici, vedere le sezioni successive alla tabella.

Requisito	Sezione specifica UEFI	Note
tabella di sistema EFI	4.3	Requisito esplicito di Windows
servizi di avvio EFI	6.0
Servizi di eventi, timer e attività.	6.1
Servizi di memoria	6.2	Requisito esplicito di Windows'
Servizi del gestore del protocollo	6.3	Requisito esplicito di Windows
Servizi di immagine	6.4	Requisito esplicito di Windows
Servizi vari	6.5	Requisito esplicito di Windows
dei servizi di runtime EFI	7.0
Servizi temporali	7.3	Requisito esplicito di Windows
Servizi variabili	7.2	Requisito esplicito di Windows
Servizi vari	7.5	Requisito esplicito di Windows
protocolli UEFI necessari
Protocollo immagine caricato da EFI	8.1
Protocollo di percorso del dispositivo immagine caricato da EFI	8.2
Il protocollo del percorso del dispositivo EFI	9.2	Requisito esplicito di Windows
Protocollo di utilità del percorso del dispositivo EFI	9.5
Protocollo di decompressione EFI	18,5
Protocollo interprete EBC	20.11
protocolli UEFI richiesti in modo condizionale
Protocollo di input di testo semplice EFI	11.3	Requisito esplicito di Windows
Protocollo EX di input di testo semplice EFI	11.2
Protocollo di output di testo semplice EFI	11.4
Protocollo di output della grafica EFI	11.9	Requisito esplicito di Windows
Protocollo EFI EDID individuato	11.9.1
Protocollo attivo EFI EDID	11.9.1
Protocollo I/O di blocco EFI	12.8	Requisito esplicito di Windows
Protocollo I/O del disco EFI	12.7
Protocollo di file system semplice EFI	12,4
Protocollo di confronto Unicode EFI	12.10
Protocollo di rete semplice EFI	21.1
Protocollo di codice di base PXE EFI	21.3
Protocollo dei servizi di integrità dell'avvio EFI	21.5
Protocollo I/O seriale EFI	11.8
Supporto UEFI ARM	2.3.5	Requisito esplicito di Windows
requisiti di sicurezza
Avvio protetto	27.0	Requisito esplicito di Windows
Requisiti del gestore di avvio	3.1, 3.3	Requisito esplicito di Windows

Requisiti della tabella di sistema EFI

La tabella di sistema EFI deve essere conforme alla definizione standard a livello di revisione implementata. La tabella di configurazione a cui punta la tabella di sistema EFI deve includere i due GUID e i puntatori associati descritti nella tabella seguente.

GUID (Identificatore Globale Unico)	Descrizione
EFI_ACPI_Table GUID	Questo GUID deve puntare al puntatore RSDP (ACPI Root System Description Pointer) per la piattaforma.
SMBIOS_Table GUID	Questo GUID deve puntare alla struttura del punto di ingresso SMBIOS. Windows richiede la specifica SMBIOS, a livello di revisione 2.4 o superiore. Sono necessarie le sezioni 3.2, "Strutture e dati obbligatori" e 4 "Linee guida di conformità". È disponibile un test di compatibilità SMBIOS di Windows.

Requisiti dei servizi di avvio EFI

La tabella seguente elenca i requisiti dei servizi di avvio EFI per Windows.

Servizio di avvio EFI	Requisito
Servizi di memoria	Windows richiede tutti i servizi di memoria.
Servizi del gestore del protocollo	Windows richiede i servizi del gestore di protocolli seguenti: OpenProtocol() CloseProtocol() LocateDevicePath() LocateHandle()
Servizi di immagine	Windows richiede i servizi di immagine seguenti: ExitBootServices()
Vari servizi di avvio	Windows richiede i seguenti servizi di avvio vari: Stall() Nota: L'implementazione Stall() deve avere un errore deterministico (ripetibile), in modo che la correzione o l'annullamento degli errori possa essere eseguite in modo affidabile.

Requisiti dei servizi di runtime EFI

La tabella seguente elenca i requisiti dei servizi di runtime EFI per Windows.

Servizio di runtime EFI	Requisito
Servizi di temporizzazione	Windows richiede i servizi di ora seguenti: GetTime() SetTime() Nota: i servizi temporali verranno chiamati solo durante l'avvio (prima di ExitBootServices()) per accedere all'hardware relativo all'ora del giorno sulla piattaforma.
Servizi variabili	Tutti i servizi variabili UEFI sono necessari per la gestione di più dispositivi di avvio e variabili di sicurezza nella classe di destinazione dei sistemi.
Vari servizi di runtime	Windows richiede i seguenti servizi di runtime vari: ResetSystem() Nota: L'implementazione di ResetSystem() deve supportare sia le opzioni di reimpostazione che di spegnimento.

Requisiti del protocollo

La tabella seguente descrive i protocolli UEFI richiesti da Windows per eseguire funzioni specifiche durante l'avvio.

Protocollo	Requisito
Protocollo di output della grafica	Windows richiede il protocollo GOP (Graphics Output Protocol). Requisiti specifici del buffer dei frame sono: Per gli schermi integrati, HorizontalResolution e VerticalResolution devono essere la risoluzione nativa del pannello. Per gli schermi esterni, la risoluzione orizzontale e la risoluzione verticale devono essere la risoluzione nativa dello schermo oppure, se non è supportata, i valori più alti supportati sia dalla scheda video che dallo schermo connesso. PixelPerScanLine deve essere uguale a HorizontalResolution. PixelFormat deve essere PixelBlueGreenRedReserved8BitPerColor. È necessario un buffer di frame fisico; PixelBltOnly non è supportato. Quando l'esecuzione viene passata a un'applicazione di avvio UEFI, il firmware e il gestore di avvio del firmware non devono utilizzare il buffer dei fotogrammi in alcun modo. Il buffer dei frame deve continuare a essere analizzato dopo la chiusura dei servizi di avvio.
Output di visualizzazione alternativo	Il firmware UEFI deve supportare l'avvio usando qualsiasi connettore di visualizzazione supportato dall'hardware. Se un pannello interno è connesso e visibile, è necessario usare il pannello interno. Tutti gli output con display connessi fisicamente devono mostrare la schermata di avvio. Per gli schermi connessi, il firmware UEFI deve: Inizializzare l'output con la modalità nativa dello schermo, se è possibile determinare la risoluzione nativa. Se non è possibile usare una modalità nativa, è necessario inizializzare la modalità più alta compatibile. Se non è possibile determinare le funzionalità di visualizzazione, lo schermo connesso deve essere inizializzato in una modalità nota per essere compatibile con il maggior numero possibile di monitor (in genere 640x480 o 1024x768, a 60 Hz).
Input in fase di avvio	Il protocollo EFI Simple Text Input Protocol è necessario per effettuare scelte di avvio o altre selezioni di menu nei sistemi con tastiere predefinite o tastiere collegate. Per i sistemi senza tastiera, sono consigliati tre pulsanti nell'ambiente di avvio: Pulsante di Avvio Pulsante Di aumento volume Pulsante Abbassa volume La pressione dei pulsanti deve essere segnalata tramite il protocollo EFI Simple Text Input Protocol, mappandoli rispettivamente sui seguenti tasti della tastiera: Tasto Windows Freccia su Tasto Freccia giù
Avvio dell'archiviazione locale	Windows richiede il supporto block I/O Protocol e Device Path Protocol per la soluzione di archiviazione che contiene la partizione di sistema EFI e la partizione del sistema operativo Windows. Per l'avvio dall'archiviazione flash che richiede il livellamento dell'usura o un'altra gestione della memoria flash, questa operazione deve essere implementata nel firmware (non in un'applicazione UEFI).

Requisiti di sicurezza

Windows ha requisiti di sicurezza nelle aree di avvio protetto, avvio misurato, crittografia e protezione dei dati. Questi requisiti sono descritti in dettaglio nella tabella seguente. Inoltre, per le aree in cui l'hardware SoC impedisce la conformità allo standard esistente (TPM, RTC e così via), vengono sviluppati requisiti aggiuntivi. Queste informazioni sono descritte alla fine della tabella.

Area	Requisito
Generale	Requisito 1: OBBLIGATORIO. La piattaforma deve essere conforme a tutti i requisiti specificati in questa sezione. Requisito 2: OBBLIGATORIO. Le piattaforme devono essere la classe UEFI Three senza alcun modulo di supporto per la compatibilità installato o installabile. L'emulazione BIOS e l'avvio PC/AT legacy devono essere disabilitati.
Avvio protetto UEFI	Requisito 3: OBBLIGATORIO. L'avvio protetto, come definito nella sezione 27 di UEFI v2.3.1, deve essere abilitato e con un database di firma (EFI_IMAGE_SECURITY_DATABASE) necessario per avviare in modo sicuro il computer preconfigurato. Il contenuto iniziale del database di firma è determinato dall'OEM, in base ai driver UEFI di terze parti richiesti, alle esigenze di ripristino e al caricatore di avvio del sistema operativo installato nel computer, ma deve essere inclusa una firma di EFI_CERT_X509 fornita da Microsoft. Non saranno presenti firme aggiuntive. Requisito 4: OBBLIGATORIO. È necessaria la presenza del database di firma UEFI "non consentito" (EFI_IMAGE_SECURITY_DATABASE1). Requisito 5: OBBLIGATORIO. Un KEK UEFI fornito da Microsoft deve essere incluso nel database UEFI KEK. Non saranno presenti kek aggiuntivi. Microsoft fornisce il KEK sotto forma di firma EFI_CERT_X509. Requisito 6: OBBLIGATORIO. Una chiave PKpub deve essere presente e archiviata nella flash del firmware. Nota: poiché PKpriv (la chiave privata corrispondente a PKpub) controlla i criteri di avvio protetto su tutti i dispositivi dotati di PKpub, la protezione e l'uso devono essere attentamente sorvegliati. Requisito 7: OBBLIGATORIO. I database di firma iniziali devono essere archiviati in flash del firmware e possono essere aggiornati solo con un aggiornamento del firmware firmato OEM o tramite la scrittura di variabili autenticate UEFI. Requisito 8: OBBLIGATORIO. Le immagini nel percorso di avvio che non superano la verifica della firma non devono essere eseguite e il motivo dell'errore deve essere aggiunto al EFI_IMAGE_EXECUTION_TABLE. Inoltre, l'approccio consigliato in queste situazioni è che il gestore di avvio UEFI avvia il ripristino in base a una strategia specifica dell'OEM. Requisito 9: OBBLIGATORIO. La sostituzione dell'utente fisicamente presente non deve essere consentita per le immagini UEFI che non passano la verifica della firma. Requisito 10: FACOLTATIVO. Un OEM può implementare la possibilità per un utente fisicamente presente di disattivare l'avvio protetto con accesso all'infrastruttura PKpriv o con presenza fisica tramite la configurazione del firmware. L'accesso alla configurazione del firmware può essere protetto da mezzi specifici della piattaforma (password amministratore, smart card, configurazione statica e così via) Requisito 11: OBBLIGATORIO se viene implementato il requisito 10. Se l'avvio protetto è disattivato, tutte le variabili UEFI esistenti non saranno accessibili. Requisito 12: FACOLTATIVO. Un OEM può implementare la possibilità per un utente fisicamente presente di selezionare tra due modalità di avvio protetto nella configurazione del firmware: "Personalizzato" e "Standard". La modalità personalizzata consente una maggiore flessibilità, come specificato nel codice seguente. Requisito 13: OBBLIGATORIO se viene implementato il requisito 12. È possibile riabilitare un Secure Boot disabilitato in modalità personalizzata impostando un proprietario specifico PK. L'amministrazione procederà come definito nella sezione 27.5 della specifica UEFI v2.3.1: "Firmware/OS Key Exchange." In modalità personalizzata, il proprietario del dispositivo può impostare la propria scelta di firme nei database di firma. Requisito 14: OBBLIGATORIO se viene implementato il requisito 12. La configurazione del firmware indica se l'avvio protetto è attivato e se è gestito in modalità standard o personalizzata. L'installazione del firmware fornisce un'opzione per tornare dalla modalità personalizzata a quella standard. Requisito 15: OBBLIGATORIO. Se le impostazioni del firmware vengono reimpostate sulle impostazioni predefinite, tutte le variabili protette con set personalizzato verranno cancellate e la PKpub originale verrà ristabilita insieme ai database di firme originali forniti dal produttore. Requisito 16: OBBLIGATORIO. La firma del driver userà l'opzione Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA). Requisito 17: OBBLIGATORIO. Supporto per il EFI_IMAGE_EXECUTION_INFO_TABLE , ovvero la creazione e l'archiviazione di informazioni sulle immagini avviate o non avviate durante l'avvio. Requisito 18: OBBLIGATORIO. Supporto di GetVariable() per il EFI_IMAGE_SECURITY_DATABASE (database di firma autorizzato e non consentito). Requisito 19: OBBLIGATORIO. Supporto di SetVariable() per l'EFI_IMAGE_SECURITY_DATABASE, comprendente sia il database delle firme autorizzate sia quello delle firme vietate, utilizzando il Microsoft KEK per l'autenticazione. Requisito 20: OBBLIGATORIO. EFI_HASH_SERVICE_BINDING_PROTOCOL: Supporto del servizio: CreateChild(), DestroyChild(). Requisito 21: OBBLIGATORIO. EFI_HASH_PROTOCOL. Supporto del servizio: Hash(). Supporto per gli algoritmi hash SHA_1 e SHA-256. Deve supportare il passaggio di un messaggio di almeno 10 Mbyte.
Avvio misurato UEFI	I requisiti seguenti non implicano la necessità di un'implementazione TPM TCG; tuttavia implicano una necessità di funzionalità equivalenti per le aree interessate. Il supporto della piattaforma può essere fornito da un'implementazione del firmware di un TPM in esecuzione nell'ambiente di esecuzione sicura, a livelli sopra il motore di accelerazione crittografica e sfruttando l'archiviazione isolata. Microsoft potrebbe essere in grado di fornire software di riferimento per tale implementazione TPM per l'uso da parte del fornitore. Questo è soggetto a ulteriori discussioni. Requisito 22: OBBLIGATORIO. La piattaforma deve essere conforme al protocollo EFI specificato nella UEFI Trusted Execution Environment EFI Protocol. Requisito 23: OBBLIGATORIO. La piattaforma deve rispettare la specifica della piattaforma EFI TCG con le aggiunte seguenti: Nelle piattaforme che supportano l'interfaccia definita nel protocollo TrEE EFI, il digest di PKpub deve essere esteso a TPM PCR[03] come evento EV_EFI_VARIABLE_CONFIG. Il digest del contenuto del database delle firme autorizzate (vedere la sezione 27.8 dell'elenco delle specifiche UEFI v2.3.1) deve essere esteso nell'avvio misurato come evento EV_EFI_VARIABLE_CONFIG. L'operazione di estensione deve essere eseguita su TPM PCR[03]. È possibile che un client UEFI possa leggere e analizzare l'elenco dei certificati usando la variabile EFI_IMAGE_SECURITY_DATABASE e convalidare il digest rispetto al valore esteso. I valori digest di TCG_PCR_EVENT devono essere gli SHA-256, non gli SHA-1. Requisito 24: OBBLIGATORIO. La piattaforma deve implementare il MemoryOverwriteRequestControl definito nella specifica di mitigazione degli attacchi di reimpostazione della piattaforma TCG .
Crittografia	Requisito 25: OBBLIGATORIO. La piattaforma fornirà il EFI_HASH_PROTOCOL (UEFI v2.3.1 Sezione 27.4) per l'offload delle operazioni hash crittografiche. SHA-256 deve essere supportato. Requisito 26: OBBLIGATORIO. La piattaforma supporta il EFI_RNG_PROTOCOL definito da Microsoft per la lettura pre-sistema operativo dell'entropia.
Protezione dei dati	Requisito 27: OBBLIGATORIO. La piattaforma deve supportare le variabili EFI con qualsiasi combinazione dei seguenti attributi di variabile UEFI impostati: EFI_VARIABLE_BOOTSERVICE_ACCESS VARIABILE_EFI_NON_VOLATILE EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Altri requisiti di sicurezza	I requisiti aggiuntivi seguenti sono richiesti da Windows nelle piattaforme SoC. Microsoft ha definito il protocollo per la raccolta dell'entropia da una piattaforma UEFI. Anche se non è un requisito UEFI, questo protocollo è richiesto da Windows nelle piattaforme SoC. Per altre informazioni su questo protocollo, vedere protocollo UEFI di raccolta dell'entropia. Aggiornamenti del database delle firme UEFI. È stato adottato un nuovo meccanismo per l'aggiornamento delle variabili autenticate nella sezione 27 di UEFI 2.3.1. Questo meccanismo è richiesto da Windows. Ambiente di esecuzione attendibile. Microsoft ha sviluppato un protocollo EFI per interagire con un ambiente di esecuzione attendibile (TrEE), simile per funzionalità a un sottoinsieme di un Trusted Platform Module (TPM) del Trusted Computing Group (TCG). Il protocollo EFI sfrutta in larga misura il "TCG EFI Protocol", Versione 1.2 Revisione 1.00, 9 giugno 2006, del Trusted Computing Group. Per informazioni dettagliate, consultare il protocollo UEFI Trusted Execution Environment EFI .

Requisiti del gestore di avvio del firmware

Il gestore di avvio del firmware deve supportare il comportamento di avvio predefinito definito nella sezione 3.3 della specifica. Inoltre, per il supporto multiavvio, sono necessarie variabili definite a livello globale e i requisiti del Boot Manager della sezione 3.1 della specifica.

Requisiti di associazione Arm UEFI

Il Binding UEFI per Arm include requisiti specifici per la piattaforma Arm necessari per garantire la conformità alle specifiche UEFI. Windows richiede tutti gli elementi nel collegamento ARM applicabile a ARMv7. Poiché Windows non supporta nulla precedente a ARMv7, i requisiti nell'associazione specifici per ARMv6k e versioni successive sono facoltativi.

L'associazione specifica, ad esempio, la modalità di configurazione dell'MMU e la modalità di mapping della memoria fisica. L'associazione specifica anche che le chiamate effettuate ai protocolli e ai servizi UEFI devono essere eseguite solo in ARM ISA, il che significa che il software in esecuzione in Thumb2 o Thumb dovrebbe tornare alla modalità Arm prima di chiamare le funzioni UEFI.

Requisiti di avvio del multiprocessore ARM UEFI

Microsoft ha sviluppato un protocollo per l'avvio di più core Arm in una piattaforma UEFI multiprocessore. Questo protocollo è richiesto da Windows sulle piattaforme Arm che non supportano il POWER State Coordination Interface (PSCI). Le piattaforme che supportano PSCI non devono usare questo protocollo. Per ulteriori informazioni su questo protocollo, vedere il documento Avvio multiprocessore sulle piattaforme basate su ARM UEFI sul sito Web ACPI Component Architecture (ACPICA).

Requisiti di configurazione della piattaforma

Il firmware è responsabile dell'inserimento dell'hardware di sistema in uno stato ben definito prima di passare al caricatore del sistema operativo. La tabella seguente definisce i requisiti di configurazione della piattaforma correlati.

Requisito	Descrizione
Percorso di avvio	Il firmware deve inizializzare la piattaforma fino al punto in cui Windows è in grado di accedere al dispositivo di avvio tramite UEFI e caricare il kernel. Qualsiasi dispositivo coinvolto nella gerarchia per leggere dal dispositivo di avvio deve essere sincronizzato e alimentato a un ritmo ragionevole, tenendo conto delle prestazioni e delle esigenze di potenza. Anche il core del processore di base deve essere clocked e alimentato a una velocità ragionevole, in modo che il sistema possa avviarsi in modo tempestivo senza svuotare la batteria.
Risorse di sistema principali	Le risorse di sistema di base esposte al sistema operativo tramite le tabelle ACPI devono essere alimentate e sincronizzate. Le risorse di sistema principali includono controller di interrupt, timer e controller DMA che devono essere gestiti dal sistema operativo. Inoltre, gli interrupt devono essere mascherati dalla chiamata a ExitBootServices() fino a quando il driver di dispositivo associato nel sistema operativo non smaskera e riabilita gli interrupt sul dispositivo. Se gli interrupt vengono abilitati durante i servizi di avvio, si presuppone che il firmware li gestisca.
Debug	Windows supporta il debug tramite l'host USB 3 (XHCI), l'host USB 2 (EHCI)1, IEEE 1394, le interfacce di funzione seriale e USB (oltre alle schede Ethernet PCI). Almeno uno di questi deve essere alimentato, sincronizzato e inizializzato dal firmware prima del passaggio al sistema operativo. A seconda dell'opzione fornita, deve avere una porta esposta a scopo di debug e il controller deve essere mappato alla memoria o essere connesso tramite un bus periferico dedicato (non condiviso).
Altri requisiti di configurazione della piattaforma	È necessario attuare qualsiasi configurazione di multiplexing dei pin e dei pad nel firmware prima di passare il controllo al caricatore del sistema operativo.

Requisiti di installazione

Windows richiede che la partizione del sistema operativo risieda in una soluzione di archiviazione partizionata GPT. L'archiviazione partizionata MBR può essere usata come archiviazione dei dati. Come definito nella specifica UEFI, una piattaforma UEFI richiede una partizione di sistema dedicata. Windows richiede questa partizione di sistema dedicata, detta partizione di sistema EFI (ESP).

Requisito dell'interfaccia HSTI (Hardware Security Test Interface)

La piattaforma deve implementare l'interfaccia di test della sicurezza hardware e la piattaforma è necessaria per condividere documentazione e strumenti come specificato nella specifica di testbilità della sicurezza hardware .

Articoli correlati

requisiti UEFI minimi per Windows su piattaforme SoC

requisiti UEFI per il supporto della flashing USB