Condividi tramite

Linee guida ROM per l'opzione di convalida UEFI

  • Articolo

Versione 1.3

Questo documento consente agli OEM e agli ODM di verificare che il firmware controlli le firme della relativa opzione ROM come parte della catena di avvio protetto di attendibilità.

Questa guida presuppone che si conoscano i concetti fondamentali di UEFI, la conoscenza di base dell'avvio protetto (capitoli 1, 2, 13, 20 e 27 della specifica UEFI) e del modello di sicurezza PKI.

Introduzione

Le VM delle opzioni (o OpROMs) sono firmware eseguite dal BIOS del PC durante l'inizializzazione della piattaforma. In genere vengono memorizzati su una scheda plug-in, anche se possono risiedere sulla scheda di sistema.

I dispositivi che in genere richiedono l'opzione ROM sono schede video, schede di rete e driver di archiviazione per i moduli RAID. Queste macchine virtuali di opzione forniscono anche driver firmware al PC.

Includono diversi tipi di driver del firmware, tra cui le vm ROM legacy PC-AT, Open Firmware e EFI. Esempi di driver del firmware includono il BIOS video nelle schede video, i driver di avvio PXE per le schede Ethernet e i driver di archiviazione nei controller RAID. Questi dispositivi in genere dispongono di ROM di opzione che forniscono driver del firmware.

L'interfaccia UEFI (Unified Extensible Firmware Interface) include il supporto per le macchine virtuali di opzione della modalità legacy.

In base alla specifica UEFI più recente (attualmente alle 2.3.1 Errata C – sezione 2.5.1.2), le VM delle opzioni ISA (legacy) non fanno parte della specifica UEFI. Ai fini di questa discussione, verranno considerate solo le ROM compatibili con UEFI basate su PCI.

Le VM delle opzioni possono essere usate quando non è possibile incorporare il firmware di un dispositivo nel firmware del PC. Quando l'opzione ROM trasporta il driver, l'IHV può sfruttare tale driver e mantenere il driver e il dispositivo in un'unica posizione.

Questo documento illustra il motivo per cui è necessario convalidare le VM delle opzioni e illustra alcune tecniche per farlo.

Supporto sia del BIOS UEFI che del BIOS legacy

Molti produttori creano dispositivi che includono l'opzione ROMs e firmware per molti tipi di PC. Le combinazioni comuni includono:

  • Solo ROM legacy
  • OpROM nativo UEFI
  • Legacy ROM + UEFI EBC OpROM
  • Legacy ROM + UEFI x64 OpROM
  • Legacy ROM + UEFI x64 + UEFI IA32
  • Legacy ROM + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

IL BIOS UEFI può caricare ed eseguire driver firmware legacy quando è abilitato un modulo CSM (Compatibility Support Module). Si noti che quando l'avvio protetto è abilitato, l'esecuzione del modulo di supporto compatibilità e delle VM legacy non è consentita perché i driver del firmware legacy non supportano l'autenticazione. Se il formato option ROM nella configurazione del BIOS è impostato su ROM legacy, userà sempre la ROM legacy nel dispositivo.

Se il formato OPTION ROM è impostato su COMPATIBILE CON UEFI, userà il ROM EFI più recente se presente e il ROM legacy se non è presente.

I driver UEFI sono necessari per molte delle nuove funzionalità di sicurezza a livello di firmware e per abilitare le sequenze di avvio UEFI. Ad esempio, l'installazione di Windows da un disco ottico collegato a un controller di archiviazione compatibile con UEFI non è possibile quando un sistema viene avviato in modalità UEFI quando è abilitato l'avvio protetto.

1. UEFI e ROm di opzione

diagram of uefi driver considerations

Figura 2: Considerazioni sulla sicurezza dei driver UEFI, origine: UEFI 2.3.1 Errata C

Il testo seguente ha avuto origine in UEFI 2.3.1 Errata C, ma da allora è stato modificato con informazioni dettagliate dai partnerf:

Poiché il profilo utente UEFI descrive in dettaglio una serie di privilegi correlati alla sicurezza, è importante che i provider di identità utente e le credenziali utente e l'ambiente in cui vengono eseguiti siano attendibili.

Valuta gli ambiti seguenti:

  • Protezione dell'area di archiviazione in cui sono archiviati questi driver.
  • Protezione dei mezzi in base ai quali vengono selezionati questi driver.
  • Protezione dell'ambiente di esecuzione di questi driver da driver non verificati.
  • Le strutture di dati usate da questi driver non devono essere danneggiate da driver non autorizzati mentre sono ancora in uso.

Componenti come User Identity Manager, driver user Credential e driver a bordo potrebbero trovarsi in una posizione sicura come l'unità flash protetta da scrittura, considerata attendibile dai criteri della piattaforma.

Alcuni altri driver possono risiedere in posizioni di archiviazione non protette, ad esempio roms di opzione o una partizione del disco rigido e possono essere facilmente sostituiti. Questi driver devono essere verificati.

Ad esempio, i criteri della piattaforma predefiniti devono essere in grado di verificare correttamente i driver elencati nelle opzioni di caricamento Driver##### oppure l'utente deve essere identificato prima di elaborare questi driver. In caso contrario, l'esecuzione del driver deve essere posticipata. Se il profilo utente viene modificato tramite una chiamata successiva a Identificare () o tramite l'autenticazione dinamica, le opzioni Driver#### potrebbero non essere elaborate di nuovo.

Il database del profilo utente viene chiuso usando eventi di segnale UEFI diversi in base al fatto che sia possibile proteggerlo.

Le UNITÀ UEFI Driver e UEFI opzione ROM verranno eseguite solo per i dispositivi nel percorso di avvio.

La specifica PCI consente più immagini ROM di opzione nello stesso dispositivo. Queste opzioni ROMS potrebbero essere legacy x86 e UEFI. Il firmware UEFI imposta i criteri della piattaforma per la selezione dell'opzione ROM. Ciò può fare in modo che il ROM dell'adattatore facoltativo venga eseguito come dispositivo di controllo.

Il firmware verifica le firme durante le fasi BDS e DXE. La sequenza degli eventi è la seguente:

  1. Inizializzare bus PCI e derivati
  2. Probe PCI Devices for option ROMs
  3. Le VM delle opzioni trovate vengono mappate in memoria
  4. La fase DXE carica tutti i driver UEFI nelle VM

Le VM dell'opzione UEFI possono essere ovunque in memoria. L'impostazione predefinita consiste nel consentire alla ROM nella scheda di gestire il dispositivo. UEFI consente alla piattaforma di controllare i criteri relativi all'opzione ROM che controlla quale dispositivo usa EFI_PLATFORM_DRIVER_OVERRIDE. UEFI supporta l'opzione ROMs per registrare un'interfaccia di configurazione.

In un PC con avvio protetto abilitato, i driver ROM di opzione rappresentano una minaccia per la sicurezza se non sono firmati o non vengono convalidati. La convalida della firma per le VM di opzione è un requisito WHCK. Lo stesso vale durante la manutenzione delle macchine virtuali di manutenzione per assicurarsi che l'aggiornamento venga convalidato prima dell'installazione.

Dalle specifiche e dai criteri di Windows Hardware Compatibility Program versione 1809:

  1. Controllo dell'integrità del codice del firmware firmato. Il firmware installato dall'OEM ed è di sola lettura o protetto da un processo di aggiornamento del firmware sicuro, come definito in precedenza, può essere considerato protetto. I sistemi devono verificare che tutti i componenti del firmware non protetti, i driver UEFI e le applicazioni UEFI siano firmati usando almeno RSA-2048 con SHA-256 (MD5 e SHA-1 sono vietati) e verificare che le applicazioni UEFI e i driver non firmati in base a questi requisiti non vengano eseguiti (si tratta dei criteri predefiniti per algoritmi di firma accettabili). Se non viene trovata una firma di immagini nel database autorizzato o viene trovata nel database non consentito, l'immagine non deve essere avviata e, invece, le informazioni su di esso verranno inserite nella tabella delle informazioni sull'esecuzione delle immagini.

2. Dichiarazione del problema

Alcune build del BIOS UEFI abilitato per l'avvio protetto, tra cui Tiano Core, non sono state autenticate per impostazione predefinita le ROM dell'opzione UEFI perché le VM con opzione UEFI firmate non erano disponibili durante lo sviluppo di avvio protetto. Ciò espone una superficie di attacco/vulnerabilità nell'avvio protetto UEFI.

2.1. Vulnerabilità

Questa vulnerabilità era ancora presente in EDK II e UDK2010 a partire da agosto 2013. I gestori di origine sono a conoscenza del problema e viene archiviato un bug. Qualsiasi firmware derivato da EDK II e UDK2010 deve verificare come viene gestita la verifica option ROM. Il comportamento di verifica dell'opzione ROM è controllato da un valore PcdOptionRomImageVerificationPolicy PCD nel pacchetto SECURITYPkg EDK II.

Il codice sorgente per la vulnerabilità TianoCore è Il file SecurityPkg\SecurityPkg.dec:

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

Il valore predefinito (0x00) è ALWAYS_EXECUTE, che non esegue correttamente la verifica dei driver firmati nelle macchine virtuali di opzione per le periferiche del componente aggiuntivo. Questo non è un valore ideale per qualsiasi sistema che implementa la funzionalità di avvio protetto UEFI.

Valore consigliato (migliore sicurezza): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Valore consigliato (migliore flessibilità): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

In EDK II & UDK2010, una procedura di codifica appropriata usa un meccanismo di override per modificare i valori PCD per il firmware della piattaforma. Pertanto, il valore per PcdOptionRomImageVerificationPolicy non deve essere modificato in SecurityPkg\SecurityPkg.dec. Il valore di override deve essere impostato nel file DSC della piattaforma. Di seguito è riportato un esempio che usa Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

L'override PCD deve essere inserito nella [PcdsFixedAtBuild] sezione del file DSC. Il meccanismo esatto per l'override dei parametri può variare a seconda degli strumenti del fornitore del BIOS.

Nota

Questa vulnerabilità può esistere nelle implementazioni iniziali del BIOS di avvio protetto UEFI da fornitori di BIOS indipendenti. Contattare il fornitore del BIOS per determinare se la versione potrebbe essere interessata.

3. Chi è interessato?

Un PC UEFI che implementa l'avvio protetto e ha un driver ROM di opzione UEFI che non è firmato. Inoltre, il firmware per garantire la compatibilità per ottenere il funzionamento delle schede esistenti potrebbe avere una vulnerabilità di sicurezza che non verifica le macchine virtuali di opzione.

Portatili, netbook, ultrabook e tablet: la maggior parte non sono interessati. Le VM di opzione sono in genere presenti su autobus backplane come PCI/e, ISA e i relativi derivati (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt e così via). Se un portatile non ha nessuno di questi esposti, la sua superficie di attacco è notevolmente ridotta. Inoltre, è probabile che i driver UEFI per i componenti portatili di onboarding siano integrati nel volume core del firmware BIOS, non si trova in un ROM di opzione separato. Così la maggior parte dei portatili non è a rischio. Inoltre, quando le VM dell'opzione legacy sono disabilitate, sembra che UEFI supporti solo LE MACCHINE VIRTUALI di opzione basate su PCI.

Tuttavia, se si dispone di un desktop, scheda madre o un server che dispone di un BIOS UEFI e implementare l'avvio protetto, potrebbe essere interessato. Nel controller RAID dedicato di un server o nel controller di archiviazione del componente aggiuntivo per SATA, FC e così via o nelle schede di rete PCIe Ethernet possono avere le macchine virtuali delle opzioni. I controller del componente aggiuntivo che supportano un'ampia gamma di funzionalità nei server sono comuni, quindi questo vale soprattutto per lo spazio del server.

Ciò può influire potenzialmente sui PC a 32 bit e a 64 bit, sia la classe 2 che la classe 3.

Se una piattaforma di avvio protetto supporta le VM di opzioni dai dispositivi non collegati in modo permanente alla piattaforma e supporta la possibilità di autenticare tali VM di opzione, deve supportare i metodi di convalida ROM opzione descritti in Protocolli di rete - UDP e MTFTP e le variabili EFI autenticate descritte nella specifica UEFI 2.3.1 Errata C Sezione 7.2.

4. Come testarlo?

Se si sta sviluppando il firmware ed è basato su Tiano Core, verificare la vulnerabilità menzionata nella sezione 2.1. Se usi un altro firmware IBV, controllali. In alternativa, è possibile eseguire il test manualmente, come indicato di seguito.

È necessario quanto segue:

  • PC sottoposto a test con firmware UEFI
  • Dispositivo PCI con Opzione ROM nel PC sottoposto a test (ad esempio una scheda video)
  • Assicurarsi che l'avvio protetto sia abilitato

Passaggi per il test:

  1. Inserire un componente aggiuntivo UEFI nella scheda PCI con UEFI Option ROM nel PC sottoposto a test.

    Se si usa una scheda video PCI per il test, collegare un monitor esterno.

  2. Abilitare l'avvio protetto con le impostazioni seguenti:

    • PK: pk o pks autofirmato
    • KEK: MS KEK, test PK-signed Fabrikam KEK o un'altra chiave kek
    • DB: NULL. Deve essere NULL.
    • DBX: NULL.
    • SecureBoot: la variabile UEFI deve essere impostata su true

  3. Riavviare il PC

  4. Il risultato previsto è il seguente:

    • Se il firmware UEFI viene implementato correttamente, il driver ROM dell'opzione UEFI non viene caricato perché la presenza di un'opzione ROM farà in modo che il firmware controlli il "Db" per un certificato. Poiché "Db" è NULL, il driver UEFI non verrà caricato. Ad esempio, se si usa la scheda video da testare, si noterà che non viene visualizzato nulla sullo schermo.
    • Se il firmware non è implementato correttamente, il driver UEFI caricherà dall'opzione ROM perché il firmware non verifica la presenza di firme in "Db". Ad esempio, se si usa la scheda video per il test, si noterà che il monitor collegato alla scheda ROM opzione avrà la visualizzazione.

    ! [nota] Non importa se il driver ROM opzione UEFI è firmato o meno, l'opzione ROM non verrà caricata quando DB è Null e SB è abilitato (PK e KEK sono registrati).

Vedere gli script di esempio disponibili in WHCK per la generazione dell'infrastruttura a chiave pubblica e della chiave di crittografia della chiave. L'Appendice B include script di esempio e altri dettagli.

È anche possibile fare riferimento all'Appendice A per un altro approccio all'esecuzione del test precedente. Questo approccio non richiede l'impostazione del database su Null, ma richiede un driver ROM dell'opzione UEFI senza segno da IHV.

5. Come risolverlo

Se il test precedente ha esito negativo, collaborare con l'IBV per acquisire le versioni necessarie e configurarle per convalidare le VM delle opzioni. Assicurarsi che il firmware superi il test. Per i PC che hanno fornito è necessario eseguire un aggiornamento del firmware sicuro. Fare riferimento alla pubblicazione NIST 800-147 e/o vedere Windows 8.1 Secure Boot Key Creation and Management Guidance (Guida alla creazione e alla gestione della chiave di avvio protetto di Windows 8.1).

È possibile testare il PC e sfruttare Windows HCK come strumento di test (non uno strumento di certificazione) per testare l'aggiornamento del firmware sicuro.

5.1. Firma del driver

Nel caso in cui si trovino driver non firmati nelle VM dell'opzione UEFI, leggere di seguito come risolvere il problema.

Firmare singolarmente ogni driver ROM di opzione. In questo modo il formato dell'OPZIONE PCI ROM verrà interrotto. Devi firmare il driver UEFI solo prima di creare l'opzione combinata ROM.

Prima di inserire il driver UEFI in OpROM, firmare l'immagine UEFI e testarla con Secure Boot ON &OFF nella shell UEFI (caricare/scaricare il file del driver). Quindi inserire il driver connesso nell'opzione COMBINATA ROM.

È possibile indirizzare l'IHV al centro Microsoft SysDev per ottenere le VM ueFI di opzione firmate tramite un servizio disponibile tramite SysDev Center.

5.2. Convalida dell'aggiornamento

Eseguire il test menzionato in precedenza per verificare che la vulnerabilità non esista. Usare i test HCK per assicurarsi che non siano presenti regressioni funzionali.

6. Risorse

Appendice A: Approccio alternativo al test con driver ROM di opzioni non firmate

Questo approccio si basa sul recupero di strumenti da IHV per assicurarsi che il driver ROM dell'opzione UEFI sia firmato.

È necessario quanto segue:

  • PC sottoposto a test con firmware UEFI
  • Dispositivo PCI con un driver OPTION ROM non firmato collegato al PC sottoposto a test (ad esempio una scheda Video)
  • Assicurarsi che l'avvio protetto sia abilitato
  • Opzione Strumenti IHV per rilevare la firma sul driver ROM opzione se non è evidente che l'opzione driver ROM è firmato o meno

Se il firmware è implementato correttamente e l'opzione ROM è senza segno, la scheda non dovrebbe avere esito negativo per firmware e non caricare il driver sulla scheda. Il PC deve segnalare un codice di errore, ad esempio EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. Nel caso in cui usi una scheda video, potresti vedere che il PC mostra solo una schermata nera perché l'opzione driver ROM non è stata caricata.

Se il firmware viene implementato in modo non corretto, questo test funzionerà.

Appendice B: Script per l'abilitazione dell'avvio protetto con database NULL

È possibile usare il set corrente di variabili di avvio protetto (PK e KEK) oppure generarne uno per il test.

Di seguito sono riportati i passaggi usati per generare il test PK, KEK e l'impostazione di Db su NULL. Assicurarsi che l'avvio protetto non sia abilitato; in caso contrario, questi passaggi richiederebbero file bin UEFI firmati.

Nota

È stata impostata la variabile secure boot - Db, KEK e PK in ordine inverso, quindi non è necessario firmare i file bin UEFI.

Prima di questo passaggio, il PC deve essere in modalità di configurazione.

  1. Creare certificati KEK e PK

    Questo passaggio richiede lo strumento makecert.exe disponibile in Windows SDK.

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Script per generare l'infrastruttura a chiave pubblica di test

    Di seguito è riportato un esempio.

    this scripts demonstrates how to format the Platform key
NOTE The PK is actually set in the Enable_OEM_SecureBoot.ps1 script
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "TestPK"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating PC or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "55555555-5555-5555-5555-555555555555"

$var = "PK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

Workaround relative path bug
TODO substitute OEM with your OEM name
$siglist =  $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"

$appendstring = "set_"
$attribute = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append

OutputFilePath - Specifies the name of the file created that contains the contents of what is set.
If this parameter is specified, then the content are not actually set, just stored into this file.
Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.

Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append

  3. Generare la chiave kek di test o usare la chiave KEK OEM personalizzata

    È possibile sfruttare la chiave KEK OEM o gli script di WHCK per questo.

    Di seguito è riportato un esempio.

    script to add option OEM KEK
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "Fabrikam_Test_KEK_CA"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

TODO change this path to where you have the OEM_KEK.cer file
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating system or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID

$sigowner = "00000000-0000-0000-0000-000000000000"

$var = "KEK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

$siglist = $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
if ($append -eq $false)
{
$appendstring = "set_"
$attribute = "0x27"
} else
{
$appendstring = "append_"
$attribute = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append

-Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Impostare Db su Null e impostare KEK e PK

    La prima operazione eseguita da questo script è l'impostazione del database su Null.

    Nota

    Tenere presente se la CA KEK di test di Fabrikam è l'unica CA KEK presente (vale a dire che non esiste una CA KEK di Windows), il PC potrebbe avviarsi in Ambiente ripristino Windows.

    Prima dell'esecuzione dello script, eseguire "Set-ExecutionPolicy Bypass -Force"

    Import-Module secureboot
try
{
Write-Host "Deleting db..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
catch
{
}
Write-Host "Setting Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK

Write-Host "Setting self-signed Test PK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK

Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."

  5. Collegare la scheda ROM e testare l'opzione

    Il test deve superare o non riuscire in base alla correttezza del firmware. Ad esempio:

    Se l'opzione ROM nel firmware viene implementata correttamente e si sta usando una scheda video per il test, non dovrebbe esserci alcun display al monitor collegato.

    Tuttavia, se si usa un firmware non corretto, la scheda video dovrebbe avere output sullo schermo.

Linee guida per la creazione e la gestione delle chiavi di avvio protetto di Windows

Panoramica dell'avvio protetto

Convalida della funzionalità della piattaforma di aggiornamento firmware UEFI di Windows