Leggendo il whitepaper , sembra doom e gloom. La pagina principale riporta "Spectre è più difficile da sfruttare di Meltdown, ma è anche più difficile da mitigare. Tuttavia, è possibile prevenire specifici exploit noti basati su Spectre tramite patch software. "
Questo sembrerebbe implicare che è non possibile prevenire exploit sconosciuti basati su Spectre attraverso patch software, è vero?
Il nucleo dell'attacco Spectre consiste nell'usare un addestramento errato del predittore di ramo della CPU per far sì che la CPU si dirizzi speculativamente su un frammento di codice selezionato da un attaccante mentre esegue il programma di destinazione, quindi osserva gli effetti indiretti dell'esecuzione di quel codice. Questo è possibile solo perché le attuali CPU condividono lo stato di predittore di branche su tutti i thread in esecuzione sul computer.
È possibile scrivere il codice x86 / amd64 immune a Spectre inserendo istruzioni che impediscono l'esecuzione speculativa dopo ogni ramo (ad esempio le istruzioni cpuid o mfence ), ma questo ha il costo di un equo grave perdita di prestazioni e può essere applicata solo al nuovo software.
Una CPU che consente di svuotare lo stato del predatore del ramo potrebbe essere resa immune da Spectre reimpostando lo stato su ciascun interruttore di contesto (a costo di alcune prestazioni). Né l'implementazione dell'architettura x86 / amd64 di Intel né quella di AMD sembrano avere una tale istruzione (ancora), ma mi aspetto che si manifesti in pochi anni. Ciò avrebbe un impatto sulle prestazioni molto inferiore rispetto a prevenire l'esecuzione speculativa, perché anche un predittore di ramo non inizializzato è accurato al 70% circa.
Qui ci sono due diverse situazioni. Uno sta eseguendo codice macchina non affidabile su una CPU. L'altro sta eseguendo codice byte o script non attendibili in un compilatore JIT, come Javascript.
modifica: ho modificato alcune cose a causa del mio fraintendimento del codice che Spectre utilizza per funzionare correttamente. Utilizza il codice esistente con privilegi più elevati con rami condizionali in cui la CPU viene deliberatamente creata per eseguire il percorso errato nel ramo con dati dannosi dati ad esso, il che si traduce in letture di memoria che vengono memorizzate nella cache e quindi eliminate. Ad eccezione del codice proof of concept, l'exploit utilizza il codice già presente nel sistema, non il proprio codice come ho detto in precedenza.
Il tracollo è correlato all'esecuzione di codice macchina non affidabile su una CPU Intel in un ambiente limitato, come un account utente limitato. Il codice può utilizzare Meltdown per accedere alla memoria protetta da lettura come la memoria del kernel che dovrebbe essere off limits. Non è correlato ai compilatori JIT.
Lo spettro è correlato a: 1) Come fusione, esecuzione di codice macchina non affidabile in un ambiente limitato e accesso a memoria limitata come la memoria del kernel. Ciò a cui si può accedere dipende da cosa viene mappato nello spazio degli indirizzi virtuali quando viene eseguito il codice vulnerabile di Spectre. 2) I complici di JIT come Javascript. Javascript e altri JIT hanno compilato ambienti con restrizioni che eseguono codice non affidabile possono essere sfruttati da Spectre per ottenere l'accesso allo spazio degli indirizzi del compilatore JIT JavaScript, del browser e probabilmente più di quello.
Il codice che è in esecuzione in un compilatore o interprete JIT ha il vantaggio di avere solo bisogno di patch per il compilatore o l'interprete JIT per risolvere il problema. Facendo in modo che lo script attaccante non possa sondare la cache può sconfiggere Spectre. Credo che il patching contro Spectre per il codice nativo sia dove diventa più difficile.
La patch di isolamento della tabella di pagina che viene utilizzata per correggere Meltdown non corregge Spectre *. Il codice vulnerabile di Spectre è un codice condizionale già presente nel sistema. Per utilizzare Spectre, questo codice viene eseguito con diversi privilegi rispetto al programma di attacco in modo che abbia accesso ai dati a cui il programma non ha accesso. Dopo che il programma di attacco ha preparato le cache e mistrains il predittore di ramo, il codice vulnerabile di Spectre viene chiamato dal programma di attacco con argomenti che causano le sue istruzioni speculativamente eseguite per leggere dalla memoria che normalmente protegge. Queste istruzioni di lettura non vengono mai completamente eseguite dalla CPU perché le scarica una volta scoperto che la previsione del ramo era sbagliata. Ma le operazioni di lettura hanno interessato le cache, e ora il programma di attacco analizza le cache per trovare i dati.
Quindi sì, è possibile creare patch software. Una volta trovato vulnerabile, i singoli condizionali possono essere modificati in modo tale che siano inutili per Spectre. Un approccio più generico di aggiunta del codice macchina dopo che tutte le istruzioni di ramo possono essere fatte per far sì che la CPU non esegua speculativamente nulla. Ciò causerà un impatto notevole sulle prestazioni, dal momento che una CPU moderna può eseguire più di 100 istruzioni in attesa di verificare una previsione di ramo! Forse si può fare una sorta di modifica del compilatore per disabilitare l'esecuzione speculativa dopo condizionali che accedono ai dati in base al valore della variabile utilizzata per il condizionale, o gli accessi alla memoria basati su dati esterni, oppure potrebbe richiedere che le variabili utilizzate in condizionali siano memorizzato in un registro per garantire che l'esecuzione speculativa sia abilitata.
* Quello che ho detto qui riguarda l'accesso alla memoria ad aree che sono leggibili dal codice vulnerabile di Spectre. Quello che non so ancora è se le istruzioni eseguite in modo speculativo possono accedere a dati protetti da lettura come fa Meltdown. Forse questo è possibile su CPU Intel e non su AMD? Sospetto che non ci siano molte discussioni su questo perché la maggior parte delle CPU sono Intel e tutto ciò che Intel è vulnerabile a Spectre è anche vulnerabile a Meltdown. Ma potrebbe importare un codice non fidato che è in esecuzione in un compilatore JIT, poiché tale codice avrebbe quindi accesso alla parte protetta da lettura dello spazio di indirizzamento del compilatore JIT (il kernel e la memoria fisica) durante l'utilizzo del codice vulnerabile di Spect che è in esecuzione con i privilegi di il compilatore JIT. Le patch di isolamento della tabella delle pagine risolverebbero questo problema, ma gli utenti potrebbero pensare che, poiché non stanno eseguendo codice nativo, non ne hanno bisogno.
Leggi altre domande sui tag spectre