Requisiti UEFI per le edizioni di Windows nelle piattaforme SoC

Questo articolo descrive i requisiti UEFI applicabili a Windows 10 per le edizioni desktop (Home, Pro, Enterprise e Education) e Windows 10 Mobile. Per i requisiti aggiuntivi che si applicano solo ai Windows 10 Mobile, vedere requisiti UEFI per Windows 10 Mobile.

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 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, i driver di dispositivo EFI o dalle catene di strumenti di sviluppo e distribuzione.

Microsoft accoglie i commenti e i commenti dei responsabili dell'implementazione in questo set di requisiti. Per eventuali requisiti di conformità UEFI che sono determinati a non essere richiesti dal sistema operativo o dal firmware, è nostra intenzione usare UEFI.org per avere questi requisiti di conformità rilassati per questa classe di dispositivo.

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 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
Servizi di runtime EFI	7.0
Servizi di tempo	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 del percorso del dispositivo immagine caricato da EFI	8.2
Protocollo di 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 di 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 individuato da EFI EDID	11.9.1
Protocollo attivo EFI EDID	11.9.1
Protocollo I/O del 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 EFI PXE	21.3
Protocollo di integrità di avvio EFI	21.5
Protocollo I/O seriale EFI	11.8
Associazione UEFI Arm	2.3.5	Requisito esplicito di Windows
Requisiti di sicurezza
Avvio protetto	27.0	Requisito esplicito di Windows
Requisiti di gestione 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 fa riferimento la tabella di sistema EFI deve includere i due GUID e i puntatori associati descritti nella tabella seguente.

GUID	Descrizione
EFI_ACPI_Table GUID	Questo GUID deve puntare al puntatore descrizione sistema radice ACPI (RSDP) 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. Le sezioni 3.2, "Strutture necessarie e dati" e 4, "Linee guida di conformità", sono necessarie. È disponibile un test di compatibilità di Windows SMBIOS.

Requisiti dei servizi di avvio EFI

Nella tabella seguente sono elencati 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 del protocollo seguenti: OpenProtocol() CloseProtocol() LocateDevicePath() LocateHandle()
Servizi di immagine	Windows richiede i servizi di immagine seguenti: ExitBootServices()
Servizi di avvio vari	Windows richiede i servizi di avvio vari seguenti: Stall() Nota: L'implementazione stall() è necessaria per avere un errore deterministico (ripetibile) in modo che sia possibile eseguire in modo affidabile la correzione o l'annullamento degli errori.

Requisiti dei servizi di runtime EFI

Nella tabella seguente sono elencati i requisiti dei servizi di runtime EFI per Windows.

Servizio runtime EFI	Requisito
Servizi di tempo	Windows richiede i servizi di ora seguenti: GetTime() SetTime() Nota: I servizi di ora verranno chiamati solo durante l'avvio (prima di ExitBootServices()) per l'accesso all'hardware della piattaforma.
Servizi variabili	Tutti i servizi variabili UEFI sono necessari per gestire più dispositivi di avvio e variabili di sicurezza nella classe di destinazione dei sistemi.
Servizi di runtime vari	Windows richiede i servizi di runtime vari seguenti: ResetSystem() Nota: L'implementazione resetSystem() deve supportare sia le opzioni di reimpostazione che di arresto.

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 grafico	Windows richiede il protocollo di output della grafica (GOP). I requisiti specifici del buffer dei frame sono: Per le visualizzazioni integrate, HorizontalResolution e VerticalResoluton devono essere la risoluzione nativa del pannello. Per gli schermi esterni, HorizontalResolution e VerticalResoluton devono essere la risoluzione nativa dello schermo oppure, se non è supportato, i valori più alti supportati sia dalla scheda video che dalla visualizzazione connessa. PixelPerScanLine deve essere uguale a HorizontalResolution. PixelFormat deve essere PixelBlueGreenRedReserved8BitPerColor. È necessario un buffer di frame fisico; PixelBltOnly non è supportato. Quando l'esecuzione viene distribuita a un'applicazione di avvio UEFI, la gestione dell'avvio del firmware e il firmware non devono usare il buffer frame per qualsiasi scopo. Il buffer dei frame deve continuare a essere analizzato dopo l'uscita 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 connessi fisicamente devono visualizzare la schermata di avvio. Per le visualizzazioni connesse, il firmware UEFI deve: Inizializzare l'output con la modalità nativa della visualizzazione, se è possibile determinare la risoluzione nativa. Se non è possibile una modalità nativa, è necessario inizializzare la modalità più alta compatibile. Se le funzionalità di visualizzazione non possono essere determinate, la visualizzazione connessa deve essere inizializzata 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 di input di testo semplice EFI è necessario per effettuare scelte di avvio o altre selezioni di menu nei sistemi con tastiere predefinite o tastiere associate. Per i sistemi senza tastiera, sono consigliati tre pulsanti nell'ambiente di avvio: Pulsante Avvia Pulsante Su volume Pulsante Volume Giù I pulsanti devono essere segnalati tramite il protocollo di input di testo semplice EFI mappandoli rispettivamente ai tasti di tastiera seguenti: Tasto WINDOWS Tasto freccia su Tasto freccia giù
Avvio dell'archiviazione locale	Windows richiede il supporto di 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 la gestione a livello di usura o di altro tipo 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 sicuro, avvio misurato, crittografia e protezione dei dati. Questi requisiti sono dettagliati nella tabella seguente. Inoltre, per tali aree in cui l'hardware SoC impedisce la conformità con lo standard esistente (TPM, RTC e così via), vengono sviluppati requisiti aggiuntivi. Queste 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 classe UEFI Tre senza moduli di supporto di compatibilità installati o installati. L'emulazione BIOS e l'avvio PC/AT legacy devono essere disabilitati.
Avvio sicuro UEFI	Requisito 3: OBBLIGATORIO. L'avvio sicuro come definito nella sezione UEFI v2.3.1 deve essere abilitato e con un database di firma (EFI_IMAGE_SECURITY_DATABASE) necessario per avviare il computer in modo sicuro pre-provisioning. Il contenuto iniziale del database di firma viene determinato dall'OEM, in base ai driver UEFI richiesti, alle esigenze di ripristino e al caricatore di avvio del sistema operativo installato nel computer, ma verrà 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. Nel database UEFI KEK fornito da Microsoft verrà incluso il database UEFI KEK. Non saranno presenti altri KEK. Microsoft fornisce il kek sotto forma di una firma di EFI_CERT_X509. Requisito 6: OBBLIGATORIO. Una chiavepub PK deve essere presente e archiviata in flash del firmware. Nota: poiché PKpriv (la controparte privata-chiave alpub PK) controlla i criteri di avvio sicuro su tutti i dispositivi di cui è stato effettuato il provisioning conpub PK, la protezione e l'uso devono essere strettamente protetti. Requisito 7: OBBLIGATORIO. I database di firma iniziale devono essere archiviati in flash del firmware e possono essere aggiornati solo con un aggiornamento del firmware con firma OEM o tramite la scrittura di variabili autenticate ueFI. Requisito 8: OBBLIGATORIO. Le immagini nel percorso di avvio che non riesce la verifica della firma non devono essere eseguite e il motivo dell'errore verrà 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. L'override utente presente fisicamente non deve essere consentito per le immagini UEFI che non riescono a verificare la firma. Requisito 10: FACOLTATIVO. Un OEM può implementare la possibilità per un utente fisicamente presente di disattivare l'avvio sicuro con accesso a 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 il requisito 10 è implementato. Se l'avvio sicuro è 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 sicuro nella configurazione del firmware: "Personalizzato" e "Standard". La modalità personalizzata consente una maggiore flessibilità, come specificato nel codice seguente. Requisito 13: OBBLIGATORIO se il requisito 12 viene implementato. Sarà possibile riabilitare un avvio protetto 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 il requisito 12 viene implementato. L'installazione del firmware indica se l'avvio sicuro è attivato e se è gestito in modalità standard o personalizzata. L'installazione del firmware fornisce un'opzione per restituire da modalità personalizzata a standard. Requisito 15: OBBLIGATORIO. Se le impostazioni del firmware vengono reimpostate per impostazione predefinita, tutte le variabili protette set personalizzate verranno cancellate e ilpub PK originale verrà riristabilito insieme ai database di firma con provisioning del produttore originale. Requisito 16: OBBLIGATORIO. La firma del driver userà l'opzione Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA). Requisito 17: OBBLIGATORIO. Supporto per la 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 database di firma EFI_IMAGE_SECURITY_DATABASE (sia autorizzato che vietato). Requisito 19: OBBLIGATORIO. Supporto di SetVariable() per il EFI_IMAGE_SECURITY_DATABASE (sia autorizzato che non consentito database di firma), usando 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; implicano tuttavia 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 un'implementazione TPM di questo tipo per l'uso da parte del fornitore. Questo è soggetto a ulteriori discussioni. Requisito 22: OBBLIGATORIO. La piattaforma deve essere conforme al protocollo EFI specificato nel protocollo EFI Trusted Execution Environment EFI di UEFI. Requisito 23: OBBLIGATORIO. La piattaforma deve rispettare la specifica della piattaforma EFI TCG con le aggiunte seguenti: Nelle piattaforme che supportano l'interfaccia definita in TrEE EFI Protocol, il digest delpub PK deve essere esteso a TPM PCR[03] come evento EV_EFI_VARIABLE_CONFIG. Il digest del contenuto del database di firma autorizzato (vedere la sezione 27.8 dell'elenco di specifiche UEFI v2.3.1) deve essere esteso nell'avvio misurato come evento EV_EFI_VARIABLE_CONFIG. L'operazione di estensione deve essere a 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. TCG_PCR_EVENT valori di digest devono essere SHA-256, non SHA-1. Requisito 24: OBBLIGATORIO. La piattaforma deve implementare memoryOverwriteRequestControl definita nella specifica di mitigazione degli attacchi di reimpostazione della piattaforma TCG.
Crittografia	Requisito 25: OBBLIGATORIO. La piattaforma fornisce la 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 la EFI_RNG_PROTOCOL definita da Microsoft per la lettura pre-sistema operativo di entropia.
Protezione dei dati	Requisito 27: OBBLIGATORIO. La piattaforma deve supportare le variabili EFI con qualsiasi combinazione degli attributi delle variabili UEFI seguenti impostate: EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Altri requisiti di sicurezza	Per le piattaforme SoC sono necessari i requisiti aggiuntivi seguenti. Microsoft ha definito il protocollo per raccogliere 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 di raccolta entropia UEFI. 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 a un subset di un subset di un modulo TCG (Trusted Computing Group) Trusted Platform Module (TPM). Il protocollo EFI sfrutta un livello elevato, "TCG EFI Protocol", versione 1.2 revisione 1.00, giugno 9, 2006, dal gruppo di calcolo attendibile. Per informazioni dettagliate, vedere UEFI Trusted Execution Environment EFI Protocol.

Requisiti di gestione avvio del firmware

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

Requisiti di associazione UEFI Arm

L'associazione UEFI Arm include requisiti specifici della piattaforma Arm necessaria per essere conformi alle specifiche UEFI. Windows richiede tutto nell'associazione Arm applicabile ad ARMv7. Poiché Windows non supporta nulla precedente a ARMv7, i requisiti nell'associazione specifici di ARMv6k e seguenti 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 nell'ISA arm, il che significa che il software in esecuzione in Thumb2 o Thumb deve tornare alla modalità Arm prima di chiamare le funzioni UEFI.

Requisiti di avvio del multiprocessore UEFI Arm

Microsoft ha sviluppato un protocollo per l'avvio di più core arm in una piattaforma UEFI multiprocessore. Questo protocollo è richiesto da Windows nelle piattaforme Arm che non supportano l'interfaccia di coordinamento di Power State (PSCI). Le piattaforme che supportano PSCI non devono usare questo protocollo. Per altre informazioni su questo protocollo, vedere il documento avvio multiprocessore sulle piattaforme basate su ARM UEFI nel 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 al punto in cui Windows è in grado di accedere al dispositivo di avvio tramite UEFI e caricare il kernel. Qualsiasi dispositivo coinvolto nella gerarchia da leggere dal dispositivo di avvio deve essere orologio e alimentato a una velocità ragionevole, in base alle prestazioni e alle considerazioni sulla potenza. Il core del processore di base deve anche essere orologio e alimentato a una velocità ragionevole, in modo che il sistema possa avviare in modo tempestivo senza svuotare la batteria.
Risorse di sistema principali	Le risorse di sistema di base esposte al sistema operativo tramite tabelle ACPI devono essere basate e orologiate. Le risorse di sistema principali includono controller di interruzione, timer e controller DMA che devono essere gestiti dal sistema operativo. Inoltre, gli interruzioni devono essere mascherati dalla chiamata a ExitBootServices() fino a quando il driver di dispositivo associato nel sistema operativo annulla il mascheramento e riabilita gli interruzioni nel dispositivo. Se gli interruzioni vengono abilitati durante i servizi di avvio, si presuppone che il firmware li gestisca.
Debug	Windows supporta il debug tramite HOST USB 3 (XHCI), USB 2 Host (EHCI)1, IEEE 1394, interfacce di funzione seriali e USB (nonché schede ethernet PCI). Almeno uno di questi deve essere alimentato, orologio e inizializzato dal firmware prima dell'handoff del sistema operativo. A seconda delle opzioni fornite, deve avere una porta esposta a scopo di debug e il controller deve essere mappato alla memoria o essere connesso tramite un bus di periferica dedicato (non condiviso).
Altri requisiti di configurazione della piattaforma	Qualsiasi configurazione del pin-multiplexing e pad deve essere completata nel firmware prima di assegnare il controllo al caricatore del sistema operativo.

Requisiti di installazione

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

Requisiti di Hardware Security Test Interface (HSTI)

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 le piattaforme Windows in SoC

Requisiti UEFI per Windows 10 Mobile

Requisiti UEFI per il supporto di flashing USB