Intel, bug hardware affligge CPU prodotte da 10 anni a questa parte

Nelle ultime ore sono emerse informazioni legate ad un bug presente nei processori Intel, tutti i modelli da quelli di ultima introduzione sul mercato sino alle proposte che risalgono a circa 10 anni fa, legato alla modalità di gestione della memoria virtuale.

Il bug permetterebbe ai programmi di accedere ai contenuti nella memoria che sono di pertinenza del kernel. Una soluzione via software è al momento attuale in via di implementazione per i sistemi operativi Linux, Windows e macOS: nel primo è stata già rilasciata per quanto in modo non pubblico, mentre per Windows ci si attende un fix integrato in uno dei prossimi aggiornamento del cosiddetto “patch Tuesday”.

La memoria all’interno di un sistema non è liberamente accessibile da parte dei programmi, ma viene gestita lato software dal kernel e lato hardware dalla MMU (Memory Management Unit). Il kernel ha una porzione della memoria dedicata, accessibile solo al kernel stesso e totalmente separata da quella dedicata ai programmi utente (il cosiddetto user space), così come l’esecuzione del codice avviene in due modalità differenti del processore (kernel mode e user mode). Questa separazione è legata a doppio filo alla possibilità di creare problemi nata con l’introduzione stessa dei sistemi operativi in ambienti multiprogrammati; dal momento che il kernel gestisce di fatto il sistema ed è – per fare una metafora – simile a una divinità invisibile e inconoscibile che detta vita e morte di tutto il sistema, se un programma potesse in qualche modo influenzare il kernel avrebbe di fatto il potenziale controllo dell’intero sistema.

Il problema emerso all’interno dei processori Intel riguarda la paginazione: la memoria è divisa in pagine, solitamente di 4096 byte (ovvero 1024 indirizzi di memoria da 32 bit o 512 indirizzi da 64 bit), e non esiste una netta separazione tra le tabelle delle pagine del kernel e quelle dei processi utente. Normalmente questo è possibile perché sono presenti protezioni di tipo hardware, come la distinzione tra kernel mode e user mode del processore, e non viene quindi effettuata una pulizia completa e totale della cache delle pagine. La motivazione dietro questa scelta sta nella maggiore velocità permessa da questa operazione: dato che il kernel viene invocato spesso (ad esempio ogni volta che si accede a un file), il risparmio di tempo è notevole.

Al momento del context switch, ovvero del passaggio del controllo da un programma a un altro (in questo caso dal kernel a un processo utente), la cache delle pagine non viene svuotata e aggiornata. Questo avviene perché il context switch è una delle operazioni più costose in termini di tempo per un processore, per via della lentezza della memoria. A causa di un bug ancora non meglio specificato, i processi utente riescono ad avere visibilità sulle pagine del kernel. Questo fa sì che sia per loro possibile leggere i contenuti della memoria del kernel, avere visibilità su quali siano gli indirizzi in cui questa è mappata (poiché un indirizzo in memoria virtuale non corrisponde allo stesso indirizzo in memoria fisica) e più in generale avere accesso a dati cui non dovrebbe avere accesso.

Questo porta alla possibilità di condurre attacchi mirati che sfruttano vulnerabilità più o meno note del kernel ma che richiedono la conoscenza degli indirizzi fisici, ad esempio, oltre a minare alla base la privatezza stessa del sistema.

Il bug, stando a quanto riportato da AMD, consisterebbe in un mancato controllo di sicurezza da parte del processore nell’esecuzione del codice: quest’ultimo esegue codice in maniera speculativa, andando quindi a eseguire istruzioni prima che queste vengano effettivamente richieste. Se mancasse un controllo, però, del livello di privilegio attuale (se è in esecuzione un programma utente, quindi) e viene eseguito codice in kernel mode, si creerebbe la situazione di cui sopra. Al momento mancano molti dettagli che permettano di comprendere appieno cosa avvenga e si va per ipotesi, dunque questa conclusione è da prendere con le pinze.

La correzione del bug interviene a livello di sistema operativo implementando un Kernel Page Table Isolation o KPTI, che rende il kernel di fatto invisibile ai processi che sono in esecuzione nella CPU: la cache delle pagine è quindi svuotata e ricaricata a ogni context switch, fatto che aumenta in maniera notevole l’overhead dato dal kernel.

Il fix software è richiesto necessariamente in quanto il bug può essere corretto solo a livello hardware, e lo sarà con le future versioni di processore che Intel immetterà in commercio. La soluzione software ha però una evidente controindicazione: secondo le informazioni al momento attuale disponibili introduce un impatto negativo sulle prestazioni quantificato nel 5% come minimo e nel 30-35% come massimo. La percentuale effettiva varia molto dal tipo di applicazione e potrebbe essere ben inferiore al 30% preventivato, ma è evidente come l’utilizzo della patch porti a ripercussioni negative in termini di performance.

La conseguenza pratica è che i sistemi basati su CPU Intel sono in questo momento soggetti ad una evidente penalizzazione prestazionale necessaria per correggere il bug ed evitare che da questo possano insorgere problemi di sicurezza. Pensando al numero di sistemi server basati su CPU Intel presenti nel mondo, ben si capisce quanto vasta sia la portata di questo bug e i rischi che una sua presenza possa generare in termini di attacchi.

Il bug è, come segnalato, presente all’interno dei processori Intel, mentre non vi sono problemi con quelli AMD. Queste CPU non ammettono riferimenti diretti alla memoria, inclusi i riferimenti speculativi citati sopra, che evitano il manifestarsi di questo bug. Al momento attuale il kernel Linux identifica come potenzialmente non sicuri tanto i processori Intel come quelli AMD, forzando l’abilitazione del bugfix con tutte le CPU e quindi generando un impatto prestazionale negativo anche con i processori AMD. L’azienda americana raccomanda, al momento attuale, di non abilitare questa patch in quanto non richiesta per le proprie architetture.

Vedremo nel corso delle prossime giornate quali ulteriori informazioni emergeranno, e se Intel rilascerà una posizione ufficiale. Oltre a questo sarà importante valutare gli impatti prestazionali sui tipici scenari di utilizzo sia in ambito utente che in ambito server. (fonte)