WarpGuard: Protected-Site Control-Flow Integrity for CUDA SASS Binaries

Sintesi Tecnica: WARPGUARD

Problematica
Recenti ricerche sull'exploit dimostrano che i bug nella memoria della GPU (ad esempio, gli overflow di buffer) possono scalare in una corruzione del controllo del flusso lato dispositivo. Gli attaccanti possono corrompere le continuazioni di ritorno, i puntatori a funzione, le voci delle tabelle di dispatch o i target di branch, che vengono successivamente consumati dalle istruzioni della GPU per reindirizzare l'esecuzione. Sebbene il Control-Flow Integrity (CFI) sia lo standard di difesa per le CPU, applicarlo ai binari CUDA distribuiti è complesso. I kernel di produzione sono spesso distribuiti come fatbinaries o cubins, dove il confine di sicurezza rilevante è il codice NVIDIA SASS (Streaming ASSembly) eseguito, non il codice sorgente o la rappresentazione intermedia PTX (Parallel Thread Execution).

Il livello SASS introduce complessità assenti nel CFI delle CPU:

• Trasformazioni di Lowering: Le chiamate a livello di sorgente possono essere inlined, gli stati di ritorno possono essere mantenuti nei registri invece di essere scaricati in memoria, e i target indiretti possono essere ottimizzati o eliminati.
• Esecuzione SIMT: Una singola istruzione statica può eseguire in modo differente attraverso i lane della warp (warp-uniform vs lane-local), richiedendo controlli granulari.
• Lacune di Evidenza: Non tutti i siti di controllo del flusso in un binario possiedono sufficiente evidenza per derivare una policy solida. Trattare i siti non supportati come "consentiti" crea falle di sicurezza, mentre trattarli come "protetti" senza evidenza è tecnicamente non corretto.

Gli strumenti di sicurezza GPU esistenti si concentrano sulla sicurezza della memoria o sull'iniezione di codice, ma non impongono il CFI al confine SASS eseguito con un esplicito conteggio dei siti che non possono essere protetti.

Metodologia: WARPGUARD
WARPGUARD è il primo sistema CFI progettato specificamente per i binari CUDA operanti sul SASS eseguito. Impone una policy di "sito protetto", il che significa che controlla solo i trasferimenti di controllo del flusso dove esiste sufficiente evidenza binaria per derivare una policy solida.

1. Recupero e Classificazione dei Siti:
   WARPGUARD analizza i binari SASS per identificare i siti di consumo del controllo del flusso (ritorni, chiamate indirette, branch indiretti). Classifica ogni sito in uno dei sei esiti:

   • Protetto: Esiste sufficiente evidenza; viene inserito un controllo.
   • Fixed-edge: Il target è statico (es. chiamata diretta); non è necessario un controllo dinamico.
   • Non supportato: L'evidenza è mancante o ambigua; il sito è escluso dalla protezione.
   • No-surface: Non esiste un trasferimento dinamico (es. codice completamente inlined).
   • Fallback/Escluso dal profilo: L'analisi è fallita o la modalità è disabilitata.
     Fondamentalmente, WARPGUARD non permette silenziosamente i siti non supportati; essi sono esplicitamente contabilizzati al di fuori del denominatore protetto.

2. CFI del Bordo Posteriore (Returns):
   Per i ritorni protetti, WARPGUARD autentica lo stato della continuazione prima che l'istruzione RET rilasci il controllo.

   • Meccanismo: In una chiamata protetta, il sistema registra la continuazione di ritorno attesa, l'ID della callsite, la profondità e un token cifrato (MAC) in uno stato privato affidabile del backend.
   • Verifica: Al sito di ritorno, il sistema legge la continuazione osservata, verifica il token rispetto allo stato affidabile e lo confronta con il valore atteso.
   • Sicurezza: La shadow metadata scrivibile non è autorevole; solo il token cifrato dal host/runtime affidabile autorizza il trasferimento. Se la verifica fallisce, il sistema fallisce in modo chiuso (trap) prima che avvenga il trasferimento non valido.

3. CFI del Bordo Anteriore (Chiamate/Branch Indiretti):
   Per i trasferimenti indiretti protetti, WARPGUARD valida il target dinamico rispetto a un set di target recuperato per ogni sito.

   • Recupero: I set di target sono derivati dai metadati del binario, dalle relocazioni delle costanti e dall'analisi delle tabelle di dispatch o delle funzioni che prendono indirizzi.
   • Verifica: Prima che un trasferimento indiretto venga rilasciato, il target osservato viene controllato rispetto al set consentito per quel sito specifico.
   • Granularità: I controlli sono conservativi e lane-local per impostazione predefinita per gestire la divergenza SIMT, garantendo che un lane corrotto non possa nascondersi all'interno di un aggregato warp-uniform.

4. Backend di Implementazione:
   WARPGUARD è implementato tramite tre distinti backend per separare le responsabilità:

   • WG-NVBit: Un backend di riferimento ampio che utilizza NVBit per l'instrumentation dinamica e la valutazione dell'attacco.
   • WG-ST: Un timing lane a trampolino statico per l'esecuzione senza callback su specifiche superfici sm_89, utilizzato per confrontare l'overhead senza il floor di NVBit.
   • WG-PC: Un backend di patch-cache che applica patch SASS revisionate e basate su manifest per superfici sm_89, consentendo la prevenzione senza callback.

Contributi Chiave

• Formulazione del CFI a Sito Protetto: Il documento formula il CFI dei binari CUDA come un'imposizione "check-before-release" sui siti di consumo SASS recuperati. Tiene esplicitamente conto degli edge fissi, dei siti non supportati e delle esclusioni dal profilo, separandoli dalla copertura protetta.
• Meccanismo e Implementazione: WARPGUARD lega la policy al SASS recuperato, autentica lo stato del bordo posteriore usando token cifrati, valida i target anteriori per sito e mantiene la telemetria separata dalla logica di autorizzazione.
• Valutazione con Denominatori Separati: Il sistema è valutato su 77 artefatti CUDA, classificando 51.621 siti di controllo del flusso SASS e registrando 52,2 milioni di controlli dinamici. La valutazione distingue tra superficie recuperata, enforcement protetto e superfici residue non supportate.

Risultati

• Copertura: WARPGUARD ha classificato con successo 51.621 siti, inclusi 1.343 ritorni e 154 voci di target anteriore supportate. Ha identificato 15 voci anteriori non supportate e 10 voci di fallback, assicurando che queste non fossero erroneamente trattate come protette.
• Blocco degli Attacchi: In attacchi rappresentativi di corruzione del bordo posteriore e anteriore, l'esecuzione nativa ha raggiunto il comportamento selezionato dall'attaccante, mentre l'enforcement di WARPGUARD ha fallito in modo chiuso prima di rilasciare il trasferimento non valido. Ciò è rimasto vero per:
  • Hijack dei ritorni e catene di gadget.
  • Attacchi di divergenza SIMT (ritorni di lane divergenti).
  • Corruzione del target del bordo anteriore (tabelle di dispatch, puntatori a funzione).
  • Tampering dei metadati (token, telemetria).
• Evidenza del Mondo Reale: Casi di codice pubblico (es. PPL-CUDA-SMC, PNNL SV-Sim, callback di cuFFT, GooFit) hanno confermato che gli stessi pattern di consumo SASS esistono in sistemi CUDA reali. WARPGUARD ha recuperato e protetto con successo questi siti.
• Performance:
  • WG-NVBit: Come previsto per l'instrumentation dinamica, l'overhead è stato elevato (799–927% per carichi di lavoro >50ms), dominato dai costi di dispatch degli helper e di callback.
  • WG-ST/WG-PC: Su superfici sm_89 corrispondenti, i backend senza callback hanno rimosso il floor temporale di NVBit. WG-PC ha dimostrato che la prevenzione senza callback è fattibile per i manifest revisionati, sebbene richieda una rigorosa validazione del manifest.

Significatività e Claims
Il documento afferma che WARPGUARD è, a conoscenza degli autori, il primo sistema CFI valutato per i binari CUDA che opera direttamente sul SASS eseguito. La sua significatività risiede in:

1. Spostamento del Confine: Spostare l'enforcement del CFI dal sorgente/PTX al SASS effettivamente eseguito, catturando i reali fatti del controllo del flusso (inlining, spill, maschere SIMT).
2. Contabilità Esplicita: Rifiutarsi di trattare i siti sconosciuti o non supportati come sicuri, prevenendo così le policy "allow-any" che ne minerebbero la sicurezza.
3. Enforcement Auditabile: Fornire un meccanismo per separare l'overhead di instrumentation dinamica dalla logica core del CFI e per distinguere tra siti protetti e superfici di attacco residue.

Gli autori notano con modestia che WARPGUARD non fornisce sicurezza della memoria, integrità del codice o protezione contro il compromesso lato host. È complementare agli strumenti di sicurezza della memoria, concentrandosi specificamente sul punto in cui lo stato corrotto viene consumato come controllo del flusso. Il sistema si affida a un host/runtime affidabile per la gestione delle chiavi; se lo stato privato del backend viene esposto alla GPU, le garanzie di sicurezza degradano.