Requisiti del driver ELAM

Articolo
06/15/2023

L'installazione del driver deve usare strumenti esistenti per l'installazione online e offline, registrando un driver tramite l'elaborazione inF tipica. Per il codice del driver ELAM di esempio, vedere quanto segue: https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elam

Installazione driver AM

Per garantire la compatibilità dell'installazione del driver, un driver ELAM si annuncia come un driver di avvio simile a tutti gli altri driver di avvio. INF imposta il tipo di inizio su SERVICE_BOOT_START (0), che indica che il driver deve essere caricato dal caricatore di avvio e inizializzato durante l'inizializzazione del kernel. Un driver ELAM annuncia il suo gruppo come "Early-Launch". Il comportamento di avvio anticipato per i driver in questo gruppo verrà implementato in Windows, come descritto nella sezione successiva.

Di seguito è riportato un esempio della sezione di installazione del driver di un driver ELAM INF.

[SampleAV.Service]
DisplayName    = %SampleAVServiceName%
Description    = %SampleAVServiceDescription%
ServiceType    = 1       ; SERVICE_KERNEL_DRIVER
StartType      = 0       ; SERVICE_BOOT_START
ErrorControl   = 3       ; SERVICE_ERROR_CRITICAL
LoadOrderGroup = “Early-Launch”

Poiché un driver AM non è proprietario di alcun dispositivo, è necessario installare il driver AM come legacy in modo che il driver venga aggiunto solo come servizio nel Registro di sistema. Se il driver AM è installato come normale driver PNP, verrà aggiunto alla sezione enumerazione del Registro di sistema e quindi avrà un riferimento PDO, che comporterà un comportamento indesiderato durante lo scaricamento del driver.

È anche necessario includere una sezione SignatureAttributes nel file INF per il driver ELAM.

Installazione del driver di backup

Per fornire un meccanismo di ripristino nel caso in cui il driver ELAM sia danneggiato inavvertitamente, il programma di installazione ELAM installa anche una copia del driver in un percorso di backup. In questo modo WinRE potrà recuperare la copia pulita e recuperare l'installazione.

Il programma di installazione legge il percorso del file di backup dalla chiave BackupPath archiviata in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch

Il programma di installazione inserisce quindi la copia di backup nella cartella specificata nella regkey.

Inizializzazione driver AM

Il caricatore di avvio di Windows, Winload, carica tutti i driver di avvio e le DLL dipendenti in memoria prima dell'handoff al kernel di Windows. I driver di avvio rappresentano i driver di dispositivo che devono essere inizializzati prima che lo stack di dischi sia stato inizializzato. Questi driver includono, tra gli altri, lo stack di dischi e la gestione dei volumi e i driver del file system e i driver del bus per il dispositivo del sistema operativo.

Interfaccia di callback del driver AM

I driver ELAM usano callback per fornire alla gestione PnP una descrizione di ogni driver di avvio e dll dipendente e può classificare ogni immagine di avvio come un file binario noto, noto binario non valido o un binario sconosciuto.

Il criterio predefinito del sistema operativo non consiste nell'inizializzare i driver non noti e le DLL. I criteri possono essere configurati e misurati da Winload come parte dell'attestazione di avvio.

PnP usa i criteri e la classificazione fornita dal driver AM per decidere se inizializzare ogni immagine di avvio.

Callback del Registro di sistema

I driver di avvio anticipato possono usare callback del registro di sistema o del driver di avvio per monitorare e convalidare i dati di configurazione usati come input per ogni driver di avvio. I dati di configurazione vengono archiviati nell'hive del Registro di sistema, che viene caricato da Winload ed è disponibile al momento dell'inizializzazione del driver di avvio.

Nota

Le modifiche apportate all'hive del Registro di sistema ELAM vengono rimosse prima dell'avvio del sistema. Di conseguenza, un driver ELAM deve usare la registrazione standard di Traccia eventi per Windows (ETW) anziché scrivere nel Registro di sistema.

Questi callback sono validi durante la durata del driver ELAM e verranno annullati quando il driver viene scaricato. Per altre info, vedi:

Callback del driver di avvio

Usare IoRegisterBootDriverCallback e IoUnRegisterBootDriverCallback per registrare e annullare la registrazione di un BOOT_DRIVER_CALLBACK_FUNCTION.

Questo callback fornisce aggiornamenti di stato da Windows a un driver ELAM, incluso quando tutti i driver di avvio sono stati inizializzati e la struttura di callback non è più funzionale.

Tipo di callback

L'enumerazione BDCB_CALLBACK_TYPE descrive due tipi di callback:

Callback che forniscono aggiornamenti dello stato a un driver ELAM (BdCbStatusUpdate)
Callback usati dal driver AM per classificare i driver di avvio e le DLL dipendenti prima di inizializzare le immagini (BdCbInitializeImage)

I due tipi di callback hanno strutture di contesto univoce che forniscono informazioni aggiuntive specifiche per il callback.

La struttura del contesto per il callback dell'aggiornamento dello stato contiene un singolo tipo enumerato che descrive il callout di Windows.

La struttura del contesto per il callback dell'immagine inizializza è più complessa, contenente informazioni hash e certificato per ogni immagine caricata. La struttura contiene inoltre un campo che rappresenta un parametro di output in cui il driver AM archivia il tipo di classificazione per il driver.

Un errore restituito da un callback dell'aggiornamento dello stato viene considerato come errore irreversibile e porta a un controllo di bug di sistema. In questo modo, un driver ELAM può indicare quando uno stato viene raggiunto all'esterno dei criteri AM. Ad esempio, se un driver di runtime AM non è stato caricato e inizializzato, il driver di avvio anticipato può non riuscire a scaricare il callback di preparazione per scaricare Windows per impedire a Windows di entrare in uno stato senza un driver AM caricato.

Un'immagine viene considerata sconosciuta quando viene restituito un errore dal callback dell'immagine inizializzato. I driver sconosciuti vengono inizializzati o hanno ignorato l'inizializzazione in base ai criteri del sistema operativo.

Firme malware

I dati della firma malware sono determinati dall'ISV AM, ma devono includere, almeno, un elenco approvato di hash del driver. I dati della firma vengono archiviati nel Registro di sistema in un nuovo hive "Early Launch Drivers" in HKLM caricato da Winload. Ogni driver AM ha una chiave univoca in cui archiviare l'oggetto BLOB (BLOB) binario di firma. Il percorso e la chiave del Registro di sistema hanno il formato:

HKLM\ELAM\<VendorName>\

All'interno della chiave, il fornitore è libero di definire e usare uno dei valori. Esistono tre valori blob binari definiti misurati dall'avvio misurato e il fornitore può usare ognuno di essi:

Misurato
Criteri
File di configurazione

L'hive ELAM viene scaricato dopo l'uso da parte di Early Launch Antimalware per le prestazioni. Se un servizio in modalità utente vuole aggiornare i dati della firma, deve montare il file hive dal percorso del file \Windows\System32\config\ELAM. Ad esempio, è possibile generare un UUID, convertirlo in una stringa e usarlo come chiave univoca in cui montare l'hive. Il formato di archiviazione e recupero di questi BLOB dati viene lasciato fino all'ISV, ma i dati di firma devono essere firmati in modo che il driver AM possa verificare l'integrità dei dati.

Verifica delle firme malware

Il metodo per verificare l'integrità dei dati della firma malware viene lasciato a ogni ISV AM. Le funzioni primitive crittografiche CNG sono disponibili per facilitare la verifica delle firme digitali e dei certificati sui dati delle firme malware.

Errore di firma malware

Se il driver ELAM controlla l'integrità dei dati della firma e tale controllo ha esito negativo o se non sono presenti dati di firma, l'inizializzazione del driver ELAM ha ancora esito positivo. In questo caso, per ogni driver di avvio il driver ELAM deve restituire "sconosciuto" per ogni callback di inizializzazione. Inoltre, il driver ELAM deve passare queste informazioni al componente AM di runtime dopo l'avvio.

Scaricare il driver AM

Quando il callback StatusType è BdCbStatusPrepareForUnload, si tratta di un'indicazione del driver AM che tutti i driver di avvio sono stati inizializzati e che il driver AM deve prepararsi per essere scaricato. Prima di scaricare, il driver AM iniziale deve annullare la registrazione dei callback. La registrazione non può verificarsi durante un callback; invece, deve verificarsi nella funzione DriverUnload, che un driver può specificare durante DriverEntry.

Per mantenere la continuità nella protezione da malware e per garantire un handoff appropriato, il motore am di runtime deve essere avviato prima del caricamento iniziale del driver AM. Ciò significa che il motore am di runtime deve essere un driver di avvio verificato dal driver AM di avvio iniziale.

Prestazioni

Il driver deve soddisfare i requisiti di prestazioni definiti nella tabella seguente:

Scenari	Ora di Inizio	Ora fine	Upper Bound
Valutare il driver di avvio critico caricato prima di consentire l'inizializzazione. Include anche callback di aggiornamento dello stato.	Il kernel chiama nuovamente il driver antimalware per valutare il driver critico di avvio caricato.	Il driver antimalware restituisce il risultato della valutazione.	0,5ms
Valutare tutti i driver di avvio critici caricati	Il kernel chiama nuovamente il driver antimalware per valutare il primo driver critico di avvio caricato.	Il driver antimalware restituisce il risultato della valutazione per l'ultimo driver critico di avvio.	50 ms
Footprint (driver e dati di configurazione in memoria)	N/D	N/D	128kB

Inizializzazione dei driver

Dopo aver valutato i driver di avvio dal driver ELAM, il kernel usa la classificazione restituita da ELAM per decidere se inizializzare il driver. Questa decisione è dettata dai criteri e viene archiviata qui nel Registro di sistema in:

HKLM\System\CurrentControlSet\Control\EarlyLaunch\DriverLoadPolicy

Questa configurazione può essere configurata tramite Criteri di gruppo in un client aggiunto al dominio. Una soluzione antimalware può voler esporre questa funzionalità all'utente finale in scenari non gestiti. I valori seguenti sono definiti per DriverLoadPolicy:

PNP_INITIALIZE_DRIVERS_DEFAULT 0x0  (initializes known Good drivers only)
PNP_INITIALIZE_UNKNOWN_DRIVERS 0x1  
PNP_INITIALIZE_BAD_CRITICAL_DRIVERS 0x3 (this is the default setting)
PNP_INITIALIZE_BAD_DRIVERS 0x7

Errori di avvio

Se un driver di avvio viene ignorato a causa dei criteri di inizializzazione, il kernel continua a tentare di inizializzare il driver di avvio successivo nell'elenco. Questo continua fino a quando i driver non vengono inizializzati o l'avvio non è riuscito perché un driver di avvio ignorato è stato critico per l'avvio. Se l'arresto anomalo si verifica dopo l'avvio dello stack di dischi, è presente un dump di arresto anomalo e contiene alcune informazioni sul motivo o sull'arresto anomalo, per includere informazioni sui driver mancanti. Questa operazione può essere usata in WinRE per determinare la causa dell'errore e per tentare di correggere.

ELAM e Avvio misurato

Se il driver ELAM rileva una violazione dei criteri (un rootkit, ad esempio), deve chiamare immediatamente Tbsi_Revoke_Attestation per invalidare le pcr che indicano che il sistema era in uno stato valido. La funzione restituisce un errore se si verifica un problema con l'avvio misurato, ad esempio nessun TPM nel sistema.

Tbsi_Revoke_Attestation è chiamabile dalla modalità kernel. Estende PCR[12] da un valore non specificato e incrementa il contatore degli eventi nel TPM. Entrambe le azioni sono necessarie, quindi l'attendibilità viene interrotta in tutte le virgolette create da qui in avanti. Di conseguenza, i log di avvio misurati non riflettono lo stato corrente del TPM per il resto del tempo in cui il TPM è alimentato e i sistemi remoti non saranno in grado di formare attendibilità nello stato di sicurezza del sistema.

Condividi tramite