Riduzione della superficie di attacco del firmware (FASR)

Nel mese di ottobre 2019 Microsoft ha lavorato strettamente con i nostri partner OEM e Silicon per avviare PC protetti. Questi dispositivi dispongono di hardware, firmware e software integrati in modo da garantire una sicurezza avanzata per i dispositivi, l'identità e i dati. Uno dei principali pilastri di sicurezza dei PC protetti consiste nell'offrire protezione del firmware per i dispositivi. Una funzionalità basata su hardware fondamentale necessaria per soddisfare questo pilastro è Dynamic Root of Trust for Measurement (D-RTM). Tuttavia, non ci sono molti dispositivi che offrono oggi D-RTM a causa della dipendenza dal chipset sottostante per supportare questa funzionalità, che impedisce il nostro impegno per aumentare e sostenere una barra di sicurezza elevata per tutti i dispositivi Windows.

Altre operazioni possono essere eseguite per migliorare il comportamento di sicurezza di tutti i dispositivi Windows, inclusi quelli senza D-RTM. Per chiudere questo gap, Microsoft ha iniziato a collaborare con i partner per superare i problemi di compatibilità che hanno impedito l'applicazione delle protezioni della memoria nel firmware UEFI sviluppando un set di miglioramenti alla sicurezza SMM open source per offrire una maggiore flessibilità per gli OEMS da sfruttare.

Per riflettere questo impegno per la sicurezza del firmware, è stato identificato un nuovo approccio per garantire che i dispositivi possano soddisfare i requisiti di protezione del firmware dei PC protetti.

Panoramica di FASR

Per i PC protetti che non dispongono delle funzionalità D-RTM basate su hardware, è necessario definire un piccolo set di componenti del firmware che presentano una superficie di attacco ridotta e che può essere attestata nel sistema operativo. Questo approccio è denominato Riduzione della superficie di attacco firmware (FASR). Per il firmware basato su FASR per ridimensionare i PC da diversi fornitori, è necessario definire un nuovo approccio al processo di avvio del firmware.

FASR supporta due percorsi di avvio:

1. Percorso di avvio certificato:

   • È consentito eseguire solo codice attendibile, firmato e integrato da Microsoft.

   • La manomissione del percorso di avvio è rilevabile dal sistema operativo.

   La figura seguente mostra il flusso di avvio S-RTM DI FASR nel percorso di avvio certificato. Questo percorso di avvio consente di impedire l'esecuzione di codice del firmware della piattaforma imprevisto. Tuttavia, usa alcuni dati specifici della piattaforma forniti dal percorso di avvio personalizzato. Il diagramma seguente mostra il flusso di avvio FASR nel percorso di avvio certificato.

   

2. Percorso di avvio personalizzato: Tutto il codice del firmware della piattaforma può essere eseguito. Le informazioni critiche di avvio specifiche di un determinato OEM/piattaforma vengono convertite in dati nel percorso di avvio personalizzato e usate dal percorso di avvio certificato per configurare correttamente il sistema nel percorso di avvio. Il diagramma seguente mostra il flusso di avvio FASR nel percorso di avvio personalizzato.

   

   Un dispositivo FASR abilitato per la conformità del PC protetto, impostazione predefinita per il percorso di avvio certificato, a meno che non si sia verificato un evento che causa l'avvio passare al percorso di avvio personalizzato all'inizio del processo di avvio del firmware. Esempi di tali eventi includono un aggiornamento del firmware, l'utente ha richiesto un'interfaccia utente del firmware o l'utente ha scelto di disabilitare il PC protetto, il che significa che verrà sempre avviato sul percorso di avvio personalizzato fino a quando non viene riattivato.

   Si noti che l'avvio personalizzato può essere usato per avviare qualsiasi sistema operativo o software di terze parti, come supportato dal firmware della piattaforma in un dispositivo compatibile con FASR, ma Windows non riconoscerà l'avvio nel percorso di avvio personalizzato come conforme al PC protetto core.

Per comprendere meglio le tecnologie di sicurezza dietro FASR, si vuole condividere una rapida panoramica del processo di avvio di Windows.

Processo di avvio di Windows

Radice di trust

L'esecuzione iniziale del firmware in un PC moderno segue un processo di avvio in cui un set iniziale di codice carica altro codice e il livello di funzionalità si espande man mano che l'avvio viene eseguito. Ogni set di codice verifica il set successivo di codice che forma una catena di trust. Quando il firmware UEFI ottiene il controllo, segue lo standard di avvio sicuro per verificare le firme software per continuare la catena di attendibilità fino al sistema operativo. Il caricatore di avvio di Windows continua quindi la catena di attendibilità con l'avvio attendibile, che verifica ogni altro componente del sistema operativo nel processo di avvio prima del caricamento.

In generale, gli utenti malintenzionati cercano di ottenere il controllo il più presto possibile nel processo di avvio prima delle funzionalità e dei blocchi di sicurezza che consentono di proteggere il sistema sono abilitati. Quando il sistema viene disattivato, il set iniziale di codice eseguito deve essere ancorato in trust. La tecnologia di verifica hardware che soddisfa il ruolo per eseguire questa verifica anticipata del codice è denominata radice di trust. Anche se i dettagli esatti variano in base al fornitore dell'hardware, tutte le radici di attendibilità sono in genere radicate in hardware non modificabile o NELLE MACCHINE VIRTUALI nel SOC.

Avvio con misurazioni

L'avvio sicuro ancorato in una radice di trust consente di garantire che la firma digitale di tutto il firmware venga verificata; tuttavia, è anche consigliabile avere un record di esattamente ciò che il firmware eseguito. Il programma di compatibilità hardware Windows richiede che tutti i pc Windows 10 e Windows 11 includano un chip denominato TPM (Trusted Platform Module). Il TPM contiene percorsi di memoria denominati Registri di configurazione della piattaforma (PCR). Ogni PCR contiene l'hash per un tipo di codice e/o di dati caricati durante l'avvio, ad esempio il codice del firmware nel dispositivo di archiviazione non volatile (ad esempio, spi flash), le VM di opzione dai dispositivi PCI o il caricatore di avvio del sistema operativo. Le dimensioni di un valore che possono essere archiviate in un PCR sono determinate dalle dimensioni del digest dell'algoritmo hash supportato. Ad esempio, un PCR SHA-1 può archiviare 20 byte mentre un PCR SHA-2 può archiviare 32 byte. Più PCR associati allo stesso algoritmo hash sono denominati banca. La specifica del profilo TPM client TPM del PCCG definisce l'inclusione di almeno una banca PCR con 24 registri.

Con un TPM presente, ogni componente del firmware può anche aggiornare o estendere il PCR appropriato come nuovo codice e i dati vengono caricati nel processo di avvio. Il processo di estensione aggiorna il valore PCR per essere l'output dell'algoritmo hash usando il valore PCR corrente concatenato con il nuovo codice o l'argomento dati come input. Il risultato è che le pcr possono essere controllate dopo il processo di avvio per determinare cosa è stato eseguito. Ciò consente al software nel sistema operativo di comprendere se il processo di avvio è diverso dagli avvio precedenti. In un ambiente sensibile alla sicurezza, il sistema operativo può essere informato del set esatto di misurazioni di codice previste in determinati PCR per rilevare l'esecuzione di codice firmware imprevisto. Poiché i primi 16 PCR in una banca possono essere reimpostati solo reimpostando l'intero TPM, sono attendibili e la posizione preferita per archiviare misure importanti nel TPM.

Radice di attendibilità per la misurazione

Dopo aver esaminato il ruolo di una radice di trust e di come viene usato l'avvio misurato, verranno esaminati due approcci comuni per stabilire una radice di trust per segnalare una catena di misure al TPM: statico e dinamico.

Una radice statica di attendibilità per la misurazione (S-RTM) stabilisce l'attendibilità in fase di reimpostazione del sistema e richiede che l'attendibilità venga mantenuta nell'intero processo di avvio. Se l'attendibilità viene compromessa in qualsiasi momento nel processo di avvio, è irrecuperabile fino alla reimpostazione del sistema. Il diagramma seguente illustra come viene usato S-RTM nel percorso di avvio certificato.

Al contrario, la radice dinamica di trust per la misurazione (D-RTM) considera attendibile solo una piccola parte del codice firmware di inizializzazione del chipset iniziale, nonché un agente hardware usato per ristabilire l'attendibilità dinamicamente durante l'avvio. Il sistema può inizialmente avviare il codice del firmware non attendibile, ma, poco dopo l'avvio, ripristina uno stato attendibile prendendo il controllo di tutte le CPU e forzandole verso il basso in un percorso noto e misurato. Il diagramma seguente fornisce una panoramica di un flusso D-RTM tradizionale.

Esiste un compromesso tra S-RTM e D-RTM. S-RTM non richiede funzionalità hardware speciali, ma richiede software per un account migliore per il codice eseguito durante l'intero avvio. D-RTM richiede funzionalità hardware speciali, ma consente all'avvio del software in uno stato attendibile in modo dinamico durante la durata del sistema.

I PC Windows Secure-Core hanno usato un D-RTM in Avvio sicuro per consentire la flessibilità per l'ampia gamma di produttori di sistemi per implementare funzionalità e esperienze univoche nel firmware, aiutando anche a garantire che il sistema possa raggiungere uno stato attendibile e misurato che sia accettabile per ospitare un ambiente del sistema operativo sicuro. Un evento di avvio D-RTM viene usato per ripristinare l'attendibilità da un ambiente sconosciuto prima di caricare un kernel sicuro. Il diagramma seguente mostra l'evento di avvio D-RTM per ristabilire un ambiente di sistema noto.

In passato, S-RTM potrebbe essere implementato in più dispositivi a causa della mancanza di dipendenza da funzionalità hardware speciali per verificare lo stato di sicurezza del sistema, ma il sistema operativo non ha avuto un metodo affidabile per confermare che potrebbe considerare attendibili le misurazioni segnalate in qualsiasi dispositivo Windows specifico usando S-RTM.

Miglioramenti alla sicurezza del firmware

Ridurre al minimo i componenti del firmware nel percorso di avvio del sistema operativo

Un modo per considerare attendibili le misurazioni S-RTM consiste nel ridurre i componenti del firmware consentiti per l'esecuzione in un set minimo. Se tutti i dispositivi che usano S-RTM utilizzano lo stesso set di componenti del firmware, il sistema operativo deve considerare attendibile solo un singolo set di valori PCR previsti per tali componenti noti e attendibili. Con questo approccio basato su SRTM, un dispositivo può essere considerato conforme ai requisiti di protezione del firmware dei PC di base protetti quando il set di firmware di avvio viene verificato per contenere solo software firmato Microsoft che può essere certificato da Windows. Per comprendere meglio come questi componenti del firmware differiscono a quelli in un normale avvio pc, esaminiamo il processo di avvio prima e dopo.

A causa della flessibilità e del set completo di funzionalità offerte dal firmware pc moderno, il codice eseguito prima del sistema operativo comporta un aumento della superficie di attacco. Il diagramma seguente illustra un esempio di flusso di avvio S-RTM tradizionale.

Le principali responsabilità del firmware durante l'avvio possono essere notevolmente semplificate per:

• Specifica della piattaforma: funzionalità che si applica solo alla progettazione hardware della piattaforma specifica.

• Non specifico della piattaforma: funzionalità standard del settore e comuni ad altri hardware.

Un subset relativamente piccolo di firmware moderno è in genere specifico della piattaforma. Gran parte del codice dell'infrastruttura del firmware che esegue attività comuni, ad esempio l'allocazione della memoria, l'invio di driver del firmware, la gestione degli eventi e così via è uguale tra tutti (o più) sistemi basati su UEFI. I driver binari del firmware per queste attività possono essere riutilizzati tra PC. Inoltre, le specifiche e le interfacce hardware standard del settore consentono ai driver firmware comuni di inizializzare dischi rigidi, controller USB e altre periferiche. I driver binari del firmware per questo hardware possono essere riutilizzati anche nei PC. In riepilogo, i PC possono essere avviati con un set molto minimo di driver firmware comuni.

La riduzione del set totale di driver firmware caricati durante l'avvio può causare altri vantaggi:

• Tempo di avvio migliorato

• Coordinamento del fornitore ridotto per gli aggiornamenti

• Riduzione dell'esposizione di bug

• Superficie di attacco ridotta

Verifica del percorso di avvio di FASR e conformità protetta

Per un sistema FASR per soddisfare i requisiti di protezione del firmware dei PC di base protetti, deve essere stato avviato nel percorso di avvio certificato. Il firmware FASR facilita questa operazione fornendo al sistema operativo un manifesto firmato da Microsoft denominato manifesto FASR (misurato nel TPM) che contiene i valori PCR previsti per la sequenza di avvio del modulo nel percorso certificato. Questo valore può essere confrontato con la sequenza di avvio effettiva che si è verificata nel percorso certificato. Se queste misurazioni corrispondono, il sistema viene considerato in grado di soddisfare il requisito di protezione del firmware del programma PC protetto-core. Qualsiasi deviazione dalla sequenza del percorso di avvio certificato previsto comporterà l'esecuzione di misurazioni impreviste nei registri di configurazione della piattaforma (PCR) del TPM che il sistema operativo rileverà.

Inoltre, Windows rilascia solo segreti protetti da hypervisor al termine della convalida del manifesto FASR firmato in base alle misurazioni registrate durante l'avvio corrente. Se in un percorso di avvio certificato o in un aggiornamento della capsula, il manifesto FASR non è presente, la verifica della firma non riesce o si verifica una mancata corrispondenza pcr e i segreti vsm non verranno bloccati o migrati.

Come il firmware FASR risolve le protezioni della memoria e SMM

Ora che è stato definito un singolo file binario firmato da Microsoft con un set minimo di funzionalità, può includere le protezioni fondamentali ma mancanti per la sicurezza del firmware che Microsoft sta lavorando con i partner per portare sul mercato. Il percorso di avvio certificato deve soddisfare almeno i requisiti seguenti:

1. Il codice non legge/scrive in NULL/Page 0

2. Le sezioni di codice immagine e dati sono separate

3. Le sezioni dell'immagine sono allineate in un limite di pagina (4 KB)

4. I dati vengono allocati solo nei tipi di memoria dei dati e nel codice nei tipi di memoria del codice

5. Le immagini di codice non vengono caricate dal codice distribuito come file binari UEFI (solo i dispatcher designati)

6. Il codice rimane entro i limiti dei buffer di memoria allocati con pagine di protezione per le allocazioni di pagine

7. È possibile rilevare l'overflow dello stack

8. Il codice non viene eseguito dallo stack

9. La caratteristica DLL /NXCOMPAT è impostata per abilitare le protezioni NX

Le MACCHINE VIRTUALI di terze parti, le applicazioni UEFI e i driver UEFI spesso non sono stati compilati o convalidati in base a questo set di requisiti. Pertanto, non verrebbero eseguiti nel percorso di avvio certificato. Il percorso di avvio personalizzato può facoltativamente scegliere di ridurre il livello di protezione richiesto, ma tale percorso di avvio non è considerato conforme al PC protetto core dal sistema operativo.

Modalità di gestione del sistema (SMM)

SMM è una modalità operativa speciale del processore nell'architettura x86. Presenta una sfida univoca per la sicurezza del sistema perché il codice eseguito nell'ambiente SMM è opaco al sistema operativo e in genere viene eseguito al livello di privilegi più elevato (talvolta definito "Anello -2") di qualsiasi software nel processore host. Al momento dell'immissione, SMM configura il proprio ambiente configurando la tabella di pagina, interrompendo la tabella dispatch (IDT) e altre strutture di sistema. Di conseguenza, SMM rappresenta una superficie di attacco significativa che può essere sfruttata da codice dannoso per compromettere o aggirare le protezioni del sistema operativo abilitate tramite la sicurezza basata su virtualizzazione . Per ridurre il pericolo rappresentato da SMM, le funzionalità in SMM possono essere suddivise concettualmente nell'infrastruttura di base SMM e nei driver SMM come indicato di seguito:

• Core SMM: codice comune a tutte le implementazioni di SMM che eseguono responsabilità di architettura e infrastruttura

• Driver SMM: codice scritto per eseguire un'attività specifica della piattaforma in SMM

Alcuni momenti chiave del ciclo di vita di SMM sono i seguenti:

1. Quando viene stabilita la base SMM (o core), ovvero il caricamento iniziale del programma SMM (IPL)

2. Quando vengono caricati i driver SMM, denominati dispatch del driver SMM

3. Quando si verifica l'immissione in SMM, tramite un'interruzione di gestione sistema (SMI)

Caricamento iniziale del programma SMM (IPL)

La CPU dispone di funzionalità speciali che concedono al codice SMM il privilegio elevato e lo proteggono. Ad esempio, un meccanismo viene definito per immettere SMM tramite eventi software o hardware, viene usata un'istruzione CPU per restituire da SMM e diversi registri vengono definiti per controllare l'accesso e la configurazione di blocco di SMM. Molti di questi registri di controllo sono configurati dal codice IPL SMM per limitare l'accesso all'area di memoria in cui vengono archiviati il codice e i dati SMM (denominati RAM o SMRAM).

Poiché l'area SMRAM si trova nella memoria principale (DRAM), non può essere stabilita fino a quando la DRAM non è abilitata durante l'avvio. Le procedure di abilitazione della DRAM variano in base al fornitore del processore, ma alcuni megabyte di codice possono essere eseguiti direttamente dalla cache CPU LLC (incluso il codice che inizializza DRAM) prima che sia disponibile la memoria principale.

Il firmware FASR porta il punto IPL SMM prima dell'avvio rispetto alla maggior parte degli altri sistemi. Ciò riduce l'opportunità che un utente malintenzionato debba compromettere questo processo e assumere il controllo del sistema prima che SMM venga configurato. Per comprendere meglio questo e altri miglioramenti apportati a SMM nel firmware FASR, è necessario ottenere altre informazioni sul processo di avvio del firmware.

Avvio dell'inizializzazione della piattaforma (PI) nel firmware UEFI

Il firmware moderno del PC è basato su molte specifiche. La specifica UEFI definisce l'interfaccia tra un sistema operativo conforme a UEFI, ad esempio Windows e il firmware nel dispositivo. Un'altra specifica denominata Specifica di inizializzazione della piattaforma definisce il modo in cui vengono compilati i driver del firmware e dettaglia il processo di avvio stesso. A livello generale, la specifica UEFI può essere considerata come una delle standardizzazioni che consente a una singola immagine Windows di lavorare con molti dispositivi diversi e la specifica PI può essere considerata come una delle standardizzazioni che consente a tante immagini firmware di fornitori hardware diversi di lavorare insieme. Entrambe le specifiche vengono gestite dal forum UEFI.

La specifica PI definisce le fasi di avvio e quali driver vengono scritti nelle fasi di avvio. Durante l'avvio del firmware, ogni fase passa alla fase successiva e, nella maggior parte dei casi, i driver della fase di consegna non vengono più usati e solo i dati importanti vengono passati alla fase successiva in modo da poter continuare il processo di avvio. Le fasi di avvio possono essere riepilogate nel modo seguente:

1. SEC: ottenere il controllo sul vettore di reimpostazione della CPU e passare dal codice assembly al codice C per caricare PEI

2. PEI: inizializza lo stato del sistema per caricare DXE e inizializzare DRAM

3. DXE: eseguire l'inizializzazione del sistema rimanente, inclusa la fornitura del supporto BDS per caricare un sistema operativo

4. BDS: individuare l'opzione di avvio per l'avvio corrente (ad esempio, il caricatore di avvio del sistema operativo) e tentare di avviare tale opzione

5. Sistema operativo: kernel del sistema operativo

Protezione del carico iniziale del programma SMM (IPL)

Il firmware conforme alla specifica PI UEFI tradizionale carica L'IPL SMM nella fase di avvio DXE. Il firmware FASR carica l'IPL SMM nella fase di avvio PEI. La TCB (Trusted Computing Base) per un sistema è il set totale di meccanismi di protezione che lo proteggono, inclusi hardware, firmware e software. Spostando L'IPL SMM da DXE a PEI, l'intera fase DXE (che è un ambiente molto più ampio e ricco di PEI) viene rimossa dal TCB. Il diagramma seguente illustra lo spostamento di SMM IPL in precedenza nel processo di avvio UEFI.

Il codice PEI e DXE vengono eseguiti all'anello 0 e non vengono mantenuti (con poche eccezioni) nel sistema operativo. Il codice SMM viene eseguito con privilegi molto più elevati rispetto all'anello 0 (e all'hypervisor) e persiste nel sistema operativo, quindi non consente a una vulnerabilità DXE di influire sulla creazione di SMM riduce la superficie di attacco di sistema complessiva. Inoltre, poiché SMM viene avviato in precedenza nel processo di avvio, i bit di blocco impostati per proteggere SMM possono essere abilitati in precedenza nell'avvio, riducendo ulteriormente al minimo la finestra di un utente malintenzionato per compromettere SMM.

Protezione del processo di invio del driver SMM

All'interno della specifica PI, vengono definite due modalità SMM: MM tradizionale e MM autonomo. Mm tradizionale equivale al modello software SMM usato storicamente nel firmware conforme a PI, che costituisce la maggior parte del firmware UEFI nel settore. Standalone MM è una modalità relativamente nuova che modifica il modello cronologico per migliorare la sicurezza dell'ambiente SMM e prevenire errori comuni apportati nelle implementazioni mm tradizionali che hanno portato a numerose sfide di portabilità e sicurezza nel corso degli anni.

Il firmware FASR funziona esclusivamente in modalità MM autonomo. Ciò consente al firmware FASR di seguire un approccio disciplinato all'esecuzione del software in SMM. Molte vulnerabilità basate su SMM oggi sono dovute a procedure non consigliate consentite nel codice SMM in MM tradizionale che possono essere semplicemente rimosse in MM autonomo. A livello generale, ciò avviene perché, nel modello MM tradizionale, un driver SMM viene inviato due volte, una volta dal dispatcher DXE nell'anello 0, e di nuovo dal dispatcher SMM in SMM. Ciò offre un'ampia opportunità per il codice del driver eseguito nell'ambiente DXE per memorizzare nella cache i puntatori alle risorse esterne a SMRAM a cui non devono accedere dopo il ritorno del punto di ingresso. Gli attacchi che dipendono dal codice SMM per chiamare il codice all'esterno di SMM vengono spesso definiti "attacchi callout SMM".

Protezione dell'immissione in SMM

I dati vengono passati a un gestore SMI tramite una struttura denominata "buffer di comunicazione". Il gestore SMI è responsabile della convalida del fatto che i dati soddisfino determinati requisiti nel punto di ingresso. La tabella di mitigazione della sicurezza di Windows SMM (WSMT) è un meccanismo usato per attenuare la minaccia che i gestori SMI deselezionati rappresentano la sicurezza basata su virtualizzazione nel sistema operativo. Microsoft ha fornito codice al progetto TianoCore per migliorare la convalida del buffer di comunicazione. Oltre a sfruttare queste due tecniche, il codice FASR implementa anche protezioni rigorose per l'accesso alla memoria, consentendo al codice SMM di accedere solo a intervalli di memoria consentiti in modo esplicito.

Supervisore della modalità di gestione (supervisore MM)

Il codice di base SMM è comune e condiviso con minime modifiche tra i sistemi. La superficie di attacco imposta da SMM può essere notevolmente ridotta introducendo la separazione dei privilegi nell'ambiente SMM. Per questo motivo, il firmware FASR include un supervisore SMM che viene eseguito in MM autonomo. Ciò comporta un ambiente SMM ben definito con un TCB minimo con livelli di privilegio applicati dalla creazione. Il supervisore MM inserisce restrizioni per gli accessi alle porte di I/O, l'accesso MSR (Model Specific Register), l'accesso MMIO, l'accesso al salvataggio della CPU e le istruzioni consentite nell'ambiente SMM. Un criterio supervisore SMM viene usato per configurare i dettagli esatti delle risorse hardware da limitare e tali dettagli esatti sono soggetti a modifiche per ogni generazione di siliconi.

I criteri hanno recentemente eseguito la transizione a un approccio di negazione per impostazione predefinita che riduce significativamente le risorse hardware disponibili per il codice all'esterno del supervisore SMM. Questo supervisore opera senza una dipendenza hardware da qualsiasi funzionalità hardware non comunemente presente nei PC moderni.

Il supervisore MM viene usato in FASR è open source e disponibile nel repository supervisore Mu MM di Project.

Conformità del sistema FASR ai requisiti dei PC protetti

La tabella seguente indica i pilastri o gli obiettivi generali di sicurezza dei PC protetti e il modo in cui i sistemi FASR vengono avviati nel percorso certificato possono raggiungere i requisiti dei PC protetti:The following table in the certified pillars or goals of Secured-Core PC, and how FASR systems boot up in the certified path can achieve the requirements of Secured-Core PC:

Vantaggi della sicurezza	Funzionalità di sicurezza nei PC protetti
Creare una radice di attendibilità supportata dall'hardware	Avvio protetto
	Trusted Platform Module 2.0
	Protezione DMA (Direct Memory Access)
Difendersi dagli attacchi a livello di firmware (vedere la nota seguente)	Avvio sicuro Protezione del sistema (D-RTM) o S-RTM (FW FASR)
	Isolamento SMM (System Management Mode) o MM autonomo con supervisore MM (FW FASR)
Proteggere il sistema operativo dall'esecuzione di codice non verificato	Integrità della memoria (nota anche come HVCI)
Fornire la verifica e la protezione avanzata delle identità	Windows Hello
Proteggere i dati critici in caso di dispositivi smarriti o rubati	Crittografia BitLocker

Se il sistema non dispone di funzionalità di sicurezza avanzate per supportare D-RTM, i requisiti di protezione del firmware possono essere soddisfatti usando una combinazione di S-RTM e MM autonomo con supervisore MM, entrambi offerti dal firmware FASR.

Riepilogo

Questi sono alcuni degli investimenti che Microsoft ha fatto per affrontare il numero crescente di attacchi firmware che sono prevalenti oggi nel settore. Usando il codice open source per queste modifiche, stiamo consentendo ai nostri partner di sfruttare alcuni di questi vantaggi per la sicurezza che, a loro volta, trarranno vantaggio dall'ecosistema e dal settore più ampio.

L'obiettivo principale dell'iniziativa Pc core protetto è garantire che i clienti abbiano accesso ad alcune delle funzionalità di sicurezza più avanzate disponibili per i PC Windows. Con alcune di queste modifiche al firmware, siamo un passo più vicino a realizzare tale obiettivo e abbiamo aggiornato i requisiti di protezione del firmware dei PC core protetti per riflettere questa inclusione. Altre informazioni sui PC protetti sono disponibili qui.