Intel inizia il 2018 con un bel botto; nelle ultime ore sono trapelate infatti informazioni riguardanti un bug presente su tutti i loro processori prodotti da 10 anni a questa parte.
Il bug si riferisce ad un memory leak che permetterebbe alle applicazioni eseguite in user mode di accedere ad alcune aree di memoria riservate al kernel mode. Quando un processo deve eseguire delle operazioni, come aprire o scrive file, ricevere o inviare pacchetti dati in rete, ricevere un messaggio da un altro programma, di fatto si limita a chiamare le funzioni esposte dal kernel che esegue effettivamente l’operazione richiesta.
A livello processore, e semplificando un poco, chiamare una funzione od eseguire un’operazione equivale richiamare o scrivere dati di una certa cella di memoria; il kernel non è esattamente un processo come gli altri, perché con i suoi (maggiori) permessi può accedere -e manipolare- aree di memoria assegnate a processi user, mentre il contrario non è permesso.
Dato che cambiare la parte di memoria disponibile ad un processo (context switch) è un processo oneroso, le CPU moderne mantengono entrambe le aree di memoria caricate nella cache e modificano solo la visibilità della stessa ai processi; il bug sembra legato ad una particolare capacità delle CPU Intel (detta speculative reference) che, per migliori prestazioni, anticipa l’esecuzione di alcune istruzioni per poter aver già disponibile il risultato quando serve; così facendo, però, alcuni controlli di privilegio possono essere persi, permettendo alle istruzioni del processo user di accedere ad aree di memoria del processo kernel.
Purtroppo per Intel il difetto è proprio nell’hardware ed anche una patch del microcode non potrebbe risolvere la falla. Non resta altro che correggere lato sotware, il che significa lavorare a braccetto con i team di Linux, Windows e macOS per la creazione di una patch; qiesta consiste nell’implementazione della Kernel Page Table Isolation (KPTI), ovvero nell’assicurarsi che ad ogni context switch la cache della memoria venga ripulita, rendendo impossibile che un processo user possa accedere ai dati del processo kernel, che – di fatto, quindi – avrà un’area completamente separata.
Questa soluzione, però, ha un costo non indifferente in termini di performance, visto che si richiede al sistema di gestire due aree di memoria differenti per ogni syscall ed interrupt: le prime stime parlano di rallentamenti che vanno dal 15% al 30%, a seconda del tipo di carico: non proprio bruscolini!
I colleghi di Phoronix hanno applicato la patch rilasciata per Linux su alcuni sistemi ed hanno eseguito dei benchmark per capire quanto questo bug potesse impattare, confermando che la tipologia del carico è determinante, passando da nessuna penalità per programmi che lavorano esclusivamente in user space e il 50% per quelli che fanno molte operazioni in kernel space.
I manutentori del kernel Linux si sono già mossi rilasciando una patch (oscurando i dettagli nel codice sorgente visto che Intel non si è ancora pronunciata in merito); Microsoft prevede invece di rilasciare il tutto in tempo per il Patch Tuesday ed Amazon Web Services prevede un security update per venerdì.
Nel frattempo, AMD ha dichiarato di essere estranea al bug in quanto le sue CPU non permettono di fare riferimenti espliciti ad area della memoria, in particolar modo quelli speculative; tuttavia, in attesa che venga completamente esposto il bug, nella patch del kernel Linux per il problema tutte le CPU vengono trattate come “insecure_cpu”. In quelle realtà in cui la preoccupazione per l’impatto sulle performance fosse maggiore di quella sulla sicurezza (come CED in cui il software è considerato sicuro e le performance critiche, o anche solo i nostri notebook personali), la patch dovrebbe essere disattivabile.
Intanto, rimaniamo in attesa quindi dei dettagli precisi da Intel, che dovrebbero essere sollevati dall’embargo nei prossimi giorni.
Leggi il contenuto originale su Mia mamma usa Linux!