Perché le CPU sono progettate in modo tale che l'exploit "fusione" funzioni? [duplicare]

12

Sto cercando di comprendere la "fusione", ma per prima cosa capisco, ho cercato di capire gli accessi alla memoria.

Da quanto ho capito, la CPU tenta di cercare l'indirizzo virtuale nel buffer lookaside di traduzione, che indica quali dati sono nella cache della CPU. Se è lì, lo recuperiamo immediatamente. Altrimenti, cerchiamo l'indirizzo nella tabella delle pagine.

Ora dalla mia lettura, ogni processo ha la sua tabella di pagine. Tuttavia, ogni processo ha anche il kernel mappato nella sua tabella di pagina.

Presumibilmente la tabella della pagina ha anche dei bit di accesso, ovviamente non possiamo permettere la lettura direttamente nello spazio del kernel quando la CPU è in modalità utente (penso che questo sia chiamato "ring-3").

Da quanto ho capito delle tabelle di pagine, questi bit di accesso sono memorizzati nei bit inferiori dell'indirizzo. Dato che le nostre voci di pagina sono 4k, ci sono molti bit rimasti per memorizzare i bit di accesso.

Da quanto ho letto sull'exploit, il problema è che il controllo per l'accesso viene eseguito dopo che i dati sono stati recuperati. La ragione di ciò è per motivi di efficienza, vogliamo ottenere rapidamente i dati nella CPU e possiamo solo rilevare l'errore di autorizzazione prima di apportare modifiche permanenti. Ma sfortunatamente abbiamo influenzato la cache della CPU eseguendo un recupero di memoria indiretta che è rilevabile tramite attacchi temporali.

Questo schema potrebbe avere senso se la ricerca della pagina fosse economica, ma il controllo dell'accesso è costoso. Ma dalla mia comprensione non sembra essere il caso.

Ho letto la tabella delle pagine su una macchina a 64 bit con almeno tre livelli, il che significa almeno tre ricerche di memoria. Spero che questi siano nella cache, ma se non lo sono, significa cercare ricorsivamente la tabella delle pagine per le proprie pagine.

Dopo aver eseguito tutto questo lavoro e finalmente trovato la voce della tabella di pagina, quando cariciamo l'indirizzo fisico dalla tabella della pagina, carichiamo anche i bit di accesso. Perché non controllarlo lì? Sembra molto più banale controllare il bit di accesso che abbiamo già caricato piuttosto che lasciarlo a bocca aperta con i circuiti per affrontarlo in seguito.

Ovviamente mi manca qualcosa su come funziona la CPU, ma non riesco a capire cosa. Dobbiamo fare la ricerca della tabella di pagina per capire anche cosa recuperare, e una volta che siamo andati a quel problema, perché non controllare semplicemente il bit di accesso?

    
posta Clinton 08.01.2018 - 17:22
fonte

2 risposte

1

Un paio di cose che ti sei perso:

  1. La memoria del kernel in questione potrebbe già essere nella cache, rendendo il recupero dei dati altrettanto veloce quanto il recupero dei bit di accesso. È una ricerca indirizzata al contenuto per entrambi. Anche se no, c'è il TLB. Gli accessi completi alle tabelle di pagina a tre livelli non sono il caso comune da ottimizzare quando la prestazione è l'obiettivo.

  2. Il livello di privilegio stesso potrebbe essere modificato da altre istruzioni parzialmente eseguite nella pipeline. Fino a quando tali istruzioni non saranno completamente ritirate, il livello di privilegio stesso è solo una speculazione.

Mi chiedo se il # 2 porterà alla scoperta di ancora più vulnerabilità ...

    
risposta data 08.01.2018 - 20:42
fonte
0

La vera ragione è che nessuno ha compreso i problemi di sicurezza durante la progettazione. Non c'è alcuna ragione fondamentale per cui le CPU non possano essere implementate in modo sicuro e la tua domanda delinea un modo per farlo.

L'esecuzione speculativa è per le prestazioni, quindi la CPU cerca di fare tutto il lavoro che può prima dell'esecuzione effettiva, ma non può modificare lo "stato architettonico" - quale software può vedere. Il caricamento della memoria in un buffer interno non influisce sullo stato, quindi può farlo quando lo desidera. Ma causare una violazione di accesso lo influenza, quindi i progetti attuali attendono fino all'esecuzione effettiva. (Questa è una speculazione da parte mia).

Nonostante AMD non sia vulnerabile a Meltdown, sospetto che sia più fortuna che pianificare. Il documento Meltdown afferma che sia Intel che AMD eseguono ricerche speculative dopo una violazione di accesso. Non sono riusciti a creare un exploit pratico su AMD.

Una soluzione ragionevole è controllare le autorizzazioni prima delle ricerche speculative e arrestare l'esecuzione speculativa se si verificano. Quando viene raggiunta l'effettiva esecuzione, può generare un'interruzione ed evitare di lasciare effetti sul sito.

    
risposta data 08.01.2018 - 22:01
fonte

Leggi altre domande sui tag