Control-flow Enforcement (CET)

Cosa c'è da sapere

Come funziona

Gli shadow stack mantengono lo stato protetto dell'indirizzo di ritorno, mentre il tracciamento dei salti indiretti vincola le destinazioni dei salti indiretti tracciati. Gestiscono diversi trasferimenti del flusso di controllo e presentano enumerazione e abilitazione separate. Il sistema operativo, il loader, i binari dell'applicazione e le librerie concorrono alla realizzazione di un ambiente di esecuzione protetto.

Dove risulta utile

Un'applicazione compilata in modo idoneo può essere eseguita con uno shadow stack gestito dal sistema operativo, in modo tale che un indirizzo di ritorno non corrispondente generi l'eccezione prevista anziché reindirizzare l'esecuzione in modo trasparente. I criteri di compatibilità possono differire tra moduli legacy e tra la protezione in modalità utente e in modalità supervisore.

Come verificare il supporto e l'abilitazione

Verificare il bit 7 di CPUID.07H.00H:ECX per la funzionalità di shadow stack e il bit 20 di EDX per il tracciamento dei salti indiretti, quindi esaminare lo stato di protezione del processo documentato dal sistema operativo. Un bit disponibile della CPU da solo non può certificare l'applicazione della protezione per un programma in esecuzione.

Capacità, abilitazione e applicazione delle norme devono essere verificate separatamente. Un processore può supportare una protezione anche quando il sistema operativo, l'applicazione o i criteri della macchina virtuale non la attivano. Un campo di supporto all'interno di un database non costituisce l'attestazione di un sistema in esecuzione.

Cosa non stabilisce la funzionalità

La presenza di un campo CET non attesta la disponibilità o l'abilitazione di entrambe le sottofunzionalità. CET non rende un binario intrinsecamente sicuro, non previene ogni bug di corruzione della memoria né sostituisce gli aggiornamenti. Disabilitare una protezione a livello globale non costituisce una soluzione ordinaria in caso di arresto anomalo dell'applicazione.

Compatibilità e prestazioni nella pratica

Mantenere aggiornati il sistema operativo, il firmware e il runtime interessato. Se una protezione evidenzia un problema di compatibilità, ricorrere innanzitutto alla diagnostica del fornitore e agli aggiornamenti supportati. Una modifica radicale delle protezioni può influire su applicazioni non correlate e deve seguire criteri precisi di distribuzione e ripristino.

Una checklist pratica di verifica

1. Annotare il modello esatto di processore o piattaforma e le versioni di applicazione, sistema operativo e runtime interessate. Mantenere la formulazione dell'errore o del requisito effettivo.
2. Controllare la documentazione del produttore per quello specifico modello, quindi ispezionare la funzionalità effettiva e lo stato di abilitazione nell'ambiente in cui il programma viene eseguito.
3. Confrontare ogni requisito del binario o del backend selezionato. Una funzionalità con un nome simile, un alias o un'etichetta tecnologica generica non sono sufficienti.
4. Verificare che l'applicazione abbia selezionato l'implementazione prevista. Utilizzare la relativa diagnostica documentata e un fallback supportato quando i requisiti non sono soddisfatti.
5. Apportare una sola modifica supportata alla volta e ripetere lo stesso carico di lavoro. Mantenere disponibili la configurazione originale e un percorso di ripristino.

Se la funzionalità è elencata ma il software non può utilizzarla

Iniziare dal componente esatto che genera l'errore. Un database hardware descrive la capacità registrata; il sistema operativo o l'hypervisor possono esporre un ambiente effettivo differente. Un errore di istruzione illegale richiede inoltre l'analisi dell'effettiva istruzione che causa il problema e della build del binario, poiché il danneggiamento di dati o un'istruzione non supportata non correlata possono produrre un sintomo simile.

Installare la versione di applicazione, driver o runtime supportata per la piattaforma esatta e, se necessario, utilizzare la build di riferimento o di fallback documentata dal produttore. Un aggiornamento software non può creare un'istruzione che manca nel processore. Le modifiche al firmware e ai criteri di sicurezza devono seguire la procedura del produttore del sistema e un piano di ripristino, piuttosto che una generica ricetta di ottimizzazione.

Funzionalità correlate e distinzioni utili

CET-IBT · Shadow stack CET · Execute Disable (NX) · OS Guard e SMEP

Fonti e ambito di questa spiegazione

Intel 64 and IA-32 Architectures Software Developer's Manual · Kernel Linux: shadow stack di Control-flow Enforcement Technology

Questi riferimenti definiscono il comportamento architetturale e i requisiti software. Non verificano in modo indipendente ogni valore delle funzionalità presente nella pagina di un modello hardware collegato. Per il supporto su uno specifico modello, fare riferimento alle evidenze del produttore su quella pagina e controllare l'effettiva configurazione di sistema. Questo articolo non fornisce benchmark, certificazioni o date di revisione indipendente.

Correlati

Queste entità sono collegate a questo articolo. Il tipo viene mostrato per ogni collegamento.

Fonti e verifica

Titolarità editoriale: Feex. Nessuna data di revisione indipendente registrata. Come svolgiamo le ricerche.

• Intel 64 and IA-32 Architectures Software Developer's Manual · I volumi 1 e 2 descrivono le famiglie di istruzioni menzionate e CPUID; il volume 3 descrive lo stato, il paging, VMX e i controlli di protezione. La documentazione dell'architettura non certifica il supporto per un particolare modello.
• Kernel Linux: shadow stack di Control-flow Enforcement Technology · Distingue il supporto hardware, i marcatori nei binari, l'abilitazione tramite loader e la protezione attiva per thread. Descrive IBT e shadow stack come strumenti separati.