Un bug hardware affligge la memoria virtuale delle CPU Intel

Un bug hardware affligge la memoria virtuale delle CPU Intel

Emergono informazioni di un bug presente nei processori Intel che porta a problemi di sicurezza. Un fix software è in rilascio, ma introduce un tangibile impatto prestazionale

di pubblicata il , alle 08:21 nel canale Processori
IntelCoreXeonAMDEPYC
 

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.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

2110 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
axias4103 Gennaio 2018, 09:25 #1

Articolo completamente errato

Se vi riferite all'articolo https://www.theregister.co.uk/2018/...pu_design_flaw/ , cosa che data la completa assenza di fonti nel vostro è impossibile da capire, il vostro articolo è completamente sbagliato.
s-y03 Gennaio 2018, 09:42 #2
leggendo su phoronix le info complete sul bug sono sotto embargo (supppongo fino al rilascio delle patch, butta lì ma ci sta)

certo piccola non è la cosa
Opteranium03 Gennaio 2018, 09:55 #3
In effetti qualche fonte a contorno dell'articolo non guasterebbe (anzi, sarebbe consigliabile)
tmx03 Gennaio 2018, 09:58 #4
*Impatto sulle prestazioni tra il 6% e il 30% secondo i primi test. Il 30% di impatto si avrebbe solo in alcuni casi usando le tecnologie di virtualizzazione.

Di preciso non si sa ancora un granchè, mi sembra un tantinello azzardato fare previsioni al momento.
Saturn03 Gennaio 2018, 10:06 #5
Originariamente inviato da: tmx
*Impatto sulle prestazioni tra il 6% e il 30% secondo i primi test. Il 30% di impatto si avrebbe solo in alcuni casi usando le tecnologie di virtualizzazione.

Di preciso non si sa ancora un granchè, mi sembra un tantinello azzardato fare previsioni al momento.


Speriamo siano pochi questi casi, visto che tra lavoro e casa, vivo di macchine virtualizzate, per non parlare del fatto che ormai praticamente tutto il mondo server campa sulle VM, alle quali sono molto spesso assegnati compiti di una certo impatto prestazionale. Queste percentuali sono davvero poco rassicuranti...speriamo bene!
WarDuck03 Gennaio 2018, 10:52 #6
Da quello che ho letto velocemente in giro la cosa sembra molto più grave.

Qui si parla di una falla che consentirebbe a programmi che girano in user space di accedere alla memoria kernel space.

Per capire il problema bisogna comprendere come viene gestita la memoria nei sistemi operativi moderni.

Questa viene tipicamente "virtualizzata" dal sistema operativo, ovvero gli indirizzi di memoria fisici della RAM vengono tipicamente mascherati e si utilizzano indirizzi virtuali che alla bisogna vengono tradotti nei corrispondenti fisici.

Per fare un esempio si possono avere due processi che hanno nel proprio spazio di indirizzi lo stesso indirizzo virtuale A, ma che viene tradotto in indirizzi fisici diversi (A->B oppure A->C).

Nei sistemi operativi moderni la memoria viene gestita in gruppi contigui di bytes chiamate pagine (tipicamente si usano pagine da 4096 bytes). Questo perché così facendo è più efficiente effettuare la traduzione degli indirizzi virtuali in indirizzi fisici (basta tradurre il numero di pagina).

Dunque il sistema operativo tiene per ogni processo una tabella (in realtà più di una, ma è per far capire il concetto), detta tabella di paginazione che mappa gli indirizzi virtuali agli indirizzi fisici. La traduzione effettiva degli indirizzi può essere effettuata in software oppure in hardware (MMU). Per velocizzare le traduzioni esiste una cache, detta TLB che tiene le ultime traduzioni virtuale->fisico.
Altrimenti per ogni accesso ad un dato in memoria sarebbero necessari altri accessi in memoria (per scoprire la traduzione dell'indirizzo).
Ogni volta che viene effettuato un cambio di contesto dallo scheduler (quindi cambia il processo in esecuzione) è necessario cambiare le tabelle di paginazione e di conseguenza fare un flush delle cache TLB perché altrimenti il nuovo processo si troverebbe con le vecchie (ed errate) traduzioni.

Per questioni di efficienza in Linux (ma penso anche in altri OS) ogni processo tiene nelle proprie tabelle di paginazione una parte degli indirizzi virtuali associati ad indirizzi fisici del kernel. Questo perché al cambio di modalità (per esempio quando si effettua una chiamata di sistema) il kernel si trova già con le tabelle di paginazione del processo e quindi non è necessario effettuare un flush delle cache TLB.

Ci si affida ai meccanismi di protezione hardware per impedire che il processore in user mode possa accedere a quegli indirizzi. Se questa protezione viene meno tutti i processi potrebbero tendenzialmente accedere alla memoria del kernel.

La patch che stanno sviluppando dovrebbe rimuovere il mapping degli indirizzi del kernel dalle tabelle di paginazione dei processi, quindi adesso quando viene effettuata una chiamata di sistema sarebbe necessario cambiare tabelle di paginazione e di conseguenza effettuare un flush delle cache TLB, motivo per cui si perde molto in prestazioni.

Qualche link:
https://en.wikipedia.org/wiki/Kerne...table_isolation
https://lwn.net/Articles/738975/
biffuz03 Gennaio 2018, 11:06 #7
Cara REDAZIONE: ma che cavolo state dicendo, tutti i programmi saranno più lenti del 10-30%, non solo quelli virtualizzati.
È uno dei più grossi scandali della storia dell'informatica, roba da intaccare significativamente l'economia mondiale (perché le aziende dovranno potenziare di parecchio i parchi server, aumentando anche i consumi), e voi che vi vantate di redigere uno delle più importanti siti di questo paese - uno dei G8 - non avete nemmeno capito di cosa si tratta. Perché continuo a leggervi non lo so. Intanto mi tengo Adblock.

PS nel 1995 Intel mi sostituì il Pentium 60 per il bug delle divisioni, chissà se lo faranno anche stavolta...
axias4103 Gennaio 2018, 11:14 #8
Questo articolo è il punto più basso di HWU da quando lo leggo, e sono molti anni, non posso credere l'abbia scritto Corsini, troppo scadente, vi ho tolto dai miei feed. Fare confusione tra virtual memory e virtual machine...Vi leggevo pur vedendo news in ritardo anche di due giorni rispetto ad altri, ma lo imputavo a serietà e correttezza. Questo articolo dimostra invece pigrizia, ignoranza e dilettantismo.
MiKeLezZ03 Gennaio 2018, 11:32 #9
In soldoni tutte le CPU Intel hanno un'implementazione fallata del codice predittivo, il che permette di accedere al kernel space. Ciò avviene da 10 anni, ma si è scoperto solo ora ed è stato deciso che non è bello e quindi esce una patch che avrà impatti prestazionali anche del 30%. In pratica dall'oggi al domani gli Intel sono diventati spazzatura e Ryzen è diventato un processorone.
ingframin03 Gennaio 2018, 11:37 #10
Mannaggia alla ...
Mi sa che quest'anno cambio cpu

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^