Riduzione della superficie di attacco del firmware (FASR)
Nel mese di ottobre 2019, Microsoft ha lavorato a stretto contatto con i partner OEM e Silicon per lanciare PC protetti. Questi dispositivi dispongono di hardware, firmware e software completamente integrati per garantire una maggiore sicurezza per i dispositivi, l'identità e i dati. Uno dei pilastri di sicurezza principali dei PC protetti è quello di offrire la protezione del firmware per i dispositivi. Una funzionalità fondamentale basata su hardware necessaria per soddisfare questo pilastro è La radice dinamica di attendibilità per la misurazione (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 a 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 questi senza D-RTM. Microsoft collabora con i partner per risolvere i problemi di compatibilità che impedivano l'applicazione delle protezioni di memoria nel firmware UEFI sviluppando un set di miglioramenti della sicurezza SMM open source per offrire maggiore flessibilità per l'uso degli OEM.
Per riflettere questo impegno per la sicurezza del firmware, abbiamo identificato un nuovo approccio per garantire che i dispositivi possano soddisfare i requisiti di protezione del firmware dei PC core protetti.
Panoramica di FASR
Per i PC core protetti che non dispongono di funzionalità D-RTM basate su hardware, è necessario definire un piccolo set di componenti del firmware che presentano una superficie di attacco ridotta e possono essere attestati nel sistema operativo. Questo approccio è denominato Firmware Attack Surface Reduction (FASR).This approach is called Firmware Attack Surface Reduction (FASR). Per consentire la scalabilità del firmware basato su FASR tra PC di fornitori diversi, è necessario definire un nuovo approccio al processo di avvio del firmware.
FASR supporta due percorsi di avvio:
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.
Percorso di avvio personalizzato: tutto il codice del firmware della piattaforma può essere eseguito. Le informazioni critiche per l'avvio specifiche di un particolare OEM/piattaforma vengono convertite in dati nel percorso di avvio personalizzato e usate dal percorso di avvio certificato per configurare correttamente il sistema in tale 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 con core protetto, per impostazione predefinita viene impostato sul percorso di avvio certificato, a meno che non si sia verificato un evento che fa sì che l'avvio passi 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 con core protetto, vale a dire che verrà sempre avviato sul percorso di avvio personalizzato fino a quando non viene riattivato.
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 in grado di supportare 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 dell'attendibilità
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 avanza. Ogni set di codice verifica il set di codice successivo che costituisce una catena di attendibilità. Quando il firmware UEFI ottiene il controllo, segue lo standard di avvio protetto 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 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 prima possibile nel processo di avvio prima che le funzionalità di sicurezza e i blocchi che aiutano a proteggere il sistema siano 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 è detta radice di attendibilità. Anche se i dettagli esatti variano in base al fornitore dell'hardware, tutte le radici dell'attendibilità sono in genere radicate in hardware non modificabile o INMS nel SOC.
Avvio con misurazioni
L'avvio protetto ancorato in una radice di attendibilità garantisce che venga verificata la firma digitale di tutto il firmware; Tuttavia, è anche consigliabile avere un record di esattamente ciò che viene eseguito il firmware. 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 . Ogni PCR contiene l'hash per un tipo di codice e/o dati caricati durante l'avvio, ad esempio il codice del firmware nel dispositivo di archiviazione non volatile (ad esempio, flash SPI), le VM di opzione dai dispositivi PCI o il caricatore di avvio del sistema operativo. La dimensione di un valore che può essere archiviato in un PCR è determinata dalla dimensione 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 per PC TCG 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 in modo che sia l'output dell'algoritmo hash usando il valore PCR corrente concatenato con il nuovo codice o argomento dati come input. Il risultato è che le richieste pull possono essere esaminate 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 da quello degli avvio precedenti. In un ambiente sensibile alla sicurezza, il sistema operativo può essere informato del set esatto di misurazioni del 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 misurazioni importanti nel TPM.
Radice di attendibilità per la misurazione
Ora che è stato esaminato il ruolo di una radice di attendibilità e come viene usato l'avvio misurato, verranno esaminati due approcci comuni per stabilire una radice di attendibilità per segnalare una catena di misurazioni al TPM: statico e dinamico.
Una radice statica di attendibilità per la misurazione (S-RTM) stabilisce l'attendibilità al ripristino del sistema e richiede che l'attendibilità venga mantenuta durante l'intero processo di avvio. Se l'attendibilità viene compromessa in qualsiasi punto del processo di avvio, è irreversibile fino alla reimpostazione del sistema. Il diagramma seguente illustra come viene usato S-RTM nel percorso di avvio certificato.
Al contrario, Dynamic Root of Trust for Measurement (D-RTM) considera attendibile solo una piccola parte del codice firmware di inizializzazione del chipset iniziale e 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 un percorso noto e misurato. Il diagramma seguente offre una panoramica di un flusso D-RTM tradizionale.
C'è un compromesso tra S-RTM e D-RTM. S-RTM non richiede funzionalità hardware speciali, ma richiede software per tenere conto del codice eseguito durante l'intero avvio. D-RTM richiede funzionalità hardware speciali, ma consente l'avvio del software in uno stato attendibile in modo dinamico durante la durata del sistema.
I PC windows protetti con core hanno usato un D-RTM in avvio sicuro per consentire flessibilità per l'ampio set di produttori di sistemi di implementare funzionalità ed esperienze uniche nel firmware, garantendo allo stesso tempo che il sistema possa raggiungere uno stato attendibile e misurato accettabile per ospitare un ambiente del sistema operativo sicuro. Un evento di avvio D-RTM viene usato per ristabilire 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 un metodo affidabile per confermare che potrebbe considerare attendibili le misurazioni segnalate in un determinato dispositivo Windows usando S-RTM.
Miglioramenti della 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 usavano lo stesso set di componenti firmware, il sistema operativo dovrà considerare attendibile solo un singolo set di valori PCR previsti per i componenti noti e attendibili. Con questo approccio basato su SRTM, un dispositivo può essere considerato conforme al requisito di protezione del firmware dei PC protetti core quando il set di firmware di avvio viene verificato in modo da contenere solo software firmato Da Microsoft che può essere attestato da Windows. Per comprendere meglio come questi componenti del firmware differiscono rispetto a quelli in un normale avvio pc, esaminiamo il processo di avvio prima e dopo.
Grazie alla flessibilità e alla ricca gamma di funzionalità offerte dal firmware moderno del PC, il codice eseguito prima del sistema operativo comporta un aumento della superficie di attacco. Il diagramma seguente mostra un esempio di flusso di avvio S-RTM tradizionale.
Le principali responsabilità del firmware durante l'avvio possono essere notevolmente semplificate per:
Specifico 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 del firmware moderno è in genere specifico della piattaforma. Gran parte del codice dell'infrastruttura del firmware che esegue attività comuni, ad esempio l'allocazione di memoria, l'invio di driver del firmware, la gestione degli eventi e così via, è la stessa tra tutti i sistemi basati su UEFI (o la maggior parte). 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 anche essere riutilizzati nei PC. In sintesi, i PC possono essere avviati con un set minimo di driver firmware comuni.
La riduzione del set totale di driver firmware caricati durante l'avvio può portare ad 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 FASR e conformità di base protetta
Affinché un sistema FASR soddisfi i requisiti di protezione del firmware dei PC core protetti, deve essere stato avviato nel percorso di avvio certificato. Il firmware FASR semplifica 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 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.If these measurements match, the system is consider to have met the firmware protection requirement of the Secured-core PC program. Qualsiasi deviazione dalla sequenza del percorso di avvio certificato previsto comporta misurazioni impreviste effettuate nei registri di configurazione della piattaforma (PCR) del TPM rilevato dal sistema operativo.
Inoltre, Windows rilascia solo segreti protetti da hypervisor al termine della convalida del manifesto FASR firmato rispetto alle misurazioni registrate durante l'avvio corrente. Se in un percorso di avvio certificato o in un aggiornamento capsule, 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 di 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:
Il codice non legge/scrive in NULL/Page 0
Il codice dell'immagine e le sezioni dati sono separate
Le sezioni dell'immagine sono allineate in un limite di pagina (4 KB)
I dati vengono allocati solo nei tipi di memoria di dati e nel codice nei tipi di memoria del codice
Le immagini di codice non vengono caricate dal codice distribuito come file binari UEFI (solo i dispatcher designati)
Il codice rimane entro i limiti dei buffer di memoria allocati con pagine di protezione intorno alle allocazioni di pagine
È possibile rilevare l'overflow dello stack
Il codice non viene eseguito dallo stack
La caratteristica DLL /NXCOMPAT è impostata per abilitare le protezioni NX
Le VM delle opzioni di terze parti, le applicazioni UEFI e i driver UEFI spesso non sono stati compilati o convalidati in base a questo set di requisiti. Di conseguenza, non verranno eseguiti nel percorso di avvio certificato. Il percorso di avvio personalizzato può facoltativamente scegliere di abbassare il livello di protezione richiesto, ma tale percorso di avvio non è considerato conforme al PC con core protetto dal sistema operativo.
Modalità di gestione del sistema (SMM)
SMM è una modalità operativa speciale del processore nell'architettura x86. Presenta una sfida unica per la sicurezza del sistema quando il codice eseguito nell'ambiente SMM è opaco per il sistema operativo e in genere viene eseguito al livello di privilegio 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 pagine, la tabella dispatch interrupt (IDT) e altre strutture di sistema. SMM rappresenta una superficie di attacco significativa che può essere usata da codice dannoso per compromettere o aggirare le protezioni del sistema operativo abilitate tramite la sicurezza basata su virtualizzazione .SMM. Per attenuare il pericolo rappresentato da SMM, la funzionalità in SMM può essere concettualmente suddivisa nell'infrastruttura principale SMM e nei driver SMM come indicato di seguito:
Core SMM: codice comune a tutte le implementazioni di SMM che eseguono responsabilità dell'architettura e dell'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:
Quando viene stabilita la fondazione SMM (o core), il caricamento iniziale del programma SMM (IPL)
Quando vengono caricati i driver SMM, denominati SMM Driver Dispatch
Quando si verifica l'immissione in SMM, tramite un SMI (System Management Interrupt)
Caricamento iniziale del programma SMM (IPL)
La CPU dispone di funzionalità speciali che concedono al codice SMM il suo privilegio elevato e consentono di proteggerlo. Ad esempio, un meccanismo viene definito per immettere SMM tramite eventi software o hardware, viene usata un'istruzione CPU per restituire da SMM e vengono definiti diversi registri per controllare l'accesso e la configurazione del 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 codice e dati SMM (denominata RAM o SMRAM).
Poiché l'area SMRAM si trova nella memoria principale (DRAM), non può essere stabilita finché non viene abilitata la DRAM 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. In questo modo si riduce l'opportunità che un utente malintenzionato debba compromettere questo processo e assumere il controllo del sistema prima della configurazione di SMM. Per comprendere meglio questo e altri miglioramenti apportati a SMM nel firmware FASR, è necessario ottenere altre informazioni sul processo di avvio del firmware.
Avvio delle inizializzazioni della piattaforma (PI) nel firmware UEFI
Il firmware moderno del PC si basa 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 i driver del firmware vengono compilati e dettagliano 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 così tanti 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 sono 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:
SEC: ottenere il controllo nel vettore di reimpostazione della CPU e passare dal codice assembly al codice C per caricare PEI
PEI: inizializza lo stato del sistema per caricare DXE e inizializzare DRAM
DXE: eseguire l'inizializzazione del sistema rimanente, che include la fornitura del supporto BDS per caricare un sistema operativo
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
Sistema operativo: kernel del sistema operativo
Protezione del caricamento 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. Trusted Computing Base (TCB) per un sistema è il set totale di meccanismi di protezione che la proteggono, tra cui hardware, firmware e software. Spostando SMM IPL da DXE a PEI, l'intera fase DXE (che è un ambiente più ampio e ricco di PEI) viene rimossa dal TCB. Il diagramma seguente mostra la libreria IPL SMM spostata 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 più elevati rispetto all'anello 0 (e l'hypervisor) e viene mantenuto nel sistema operativo, quindi non consente a una vulnerabilità DXE di influire sulla creazione di SMM riduce la superficie di attacco complessiva del sistema. 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 sono 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 effettuati 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 appropriate 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 nel ring 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'ingresso in SMM
I dati vengono passati a un gestore SMI tramite una struttura denominata "buffer di comunicazione". Il gestore SMI è responsabile della convalida se i dati soddisfano determinati requisiti nel punto di ingresso. Windows SMM Security Mitigation Table (WSMT) è un meccanismo usato per attenuare la minaccia che i gestori SMI deselezionati rappresentano la sicurezza basata su virtualizzazione nel sistema operativo. Microsoft ha contribuito al progetto TianoCore per migliorare la convalida del buffer di comunicazione. Oltre ad applicare queste due tecniche, il codice FASR implementa anche rigorose protezioni di accesso alla memoria, consentendo al codice SMM di accedere solo agli intervalli di memoria consentiti in modo esplicito.
Supervisore della modalità di gestione (SUPERVISORE MM)
Il codice di base SMM è comune e condiviso con un minimo di nessun cambiamento 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 pone restrizioni per gli accessi alle porte I/O, agli accessi msr (Model Specific Register), all'accesso MMIO, al salvataggio dello stato della CPU e alle istruzioni consentite nell'ambiente SMM. Un criterio di 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 sono passati di recente a un approccio deny-by-default 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 trovato nei PC moderni.
Il supervisore MM viene usato in FASR è open source e disponibile nel repository supervisore di Project Mu MM.
Conformità del sistema FASR con i requisiti dei PC core 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 core protetti:
| Vantaggi per la 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 (FASR FW) |
| Isolamento SMM (System Management Mode) o MM autonomo con MM Supervisor (FASR FW) | |
| 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 MM Supervisor, 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 in tutto il settore oggi. 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 Di base protetta è garantire che i clienti abbiano accesso ad alcune delle funzionalità di sicurezza più avanzate disponibili per i PC Windows. Con alcune di queste modifiche del firmware, siamo un passo più vicino a realizzare tale obiettivo e abbiamo aggiornato i requisiti di protezione del firmware dei PC protetti per riflettere questa inclusione. Altre informazioni sui PC con core protetti sono disponibili qui.