Ottimo articolo che consiglio di leggere:
https://www.extremetech.com/computin...tive-execution
Siccome il contenuto è molto tecnico e rivolto ad un pubblico specializzato, vediamo "grosso modo" di aggiungere qualche info perchè l'articolo risulti più comprensibile a tutti.
1 - Un processore esegue una istruzione per volta e non esegue la prossima fino a che non è completata la prima, quindi più istruzioni ci sono da elaborare, più il processore deve funzionare velocemente: l'aumento della frequenza di clock era la soluzione più evidente, ma non la più performante a scapito di altre problematiche legate al surriscaldamento della componentistica interna.
2 - La potenza termica dissipata è nemica dei componenti elettronici, quindi quale soluzione adottare ?
Rivedere l'architettura per mantenere la frequenza di clock entro certi limiti ed aumentare la potenza elaborativa.
3 - Suddividere l'elaborazione di più istruzioni in un modulo a più stadi (le pipeline) sfruttando il più possibile i cicli di clock singolarmente
E veniamo al diagramma indicato:
4 - Le pipeline devono passare per forza di cose attraverso 4 stadi indicati che ricalcano il modo di operare del processore per quanto attiene l'acquisizione del dato, l'operazione da eseguire su di esso, la memorizzazione del suo stato e la prossima operazione da eseguire.
Nel grafico abbiamo 4 istruzioni che attraverso la pipeline giungono allo stato finale di elaborazione con un numero di cicli di clock ridotti rispetto a quelli necessari se privati delle pipeline.
Il processore, nell'unità di tempo, avrà sempre istruzioni e dati differenti da scomporre ed eseguire ed identificando quelle istruzioni che maggiormente vengono eseguite a scapito di altre, potrebbe risultare più veloce per certe operazioni che si presentano con maggiore frequenza.
Cosa mettere in esecuzione per prima nella pipeline è costituito dal branch prediction: L'esecuzione "azzeccata" in seguito al branch risulta speculativa, cioè non è detto sia sempre la scelta migliore.
L'articolo riporta un accuratezza del branch prediction pari al 95%, quindi quasi sempre.
Fin qui tutto bene, ma...come agisce internamente il processore in modo del tutto autonomo secondo specifiche architetturali ?
"The reason Meltdown causes such unique headaches for Intel is because Intel allows speculative execution to access privileged memory a user-space application would never be allowed to touch."
La ragione per cui Meltdown causa così tanti malditesta ad Intel è perchè consente l'esecuzione speculativa per consentire ad un applicazione in user-space di accedere a locazioni di memoria privilegiate, cosa che non normalmente non dovrebbe avvenire.
Come sarebbe a dire ? Non basta il S.O. che identifica privilegi utente e conseguenti accessi privilegiati a funzionalità precluse all'utente ma non al sistema, qualsiasi S.O. si tratti ?
Evidentemente no.
Si legge:
"Code that’s running under speculative execution doesn’t do the check whether or not memory accesses from cache are accessing privileged memory. It starts running the instructions without the privilege check, and when it’s time to commit to whether or not the speculative execution should be continued, the check will occur. But during that window, you’ve got the opportunity to run a batch of instructions against the cache without privilege checks. So you can write code with the right sequence of branch instructions to get branch prediction to work the way you want it to; and then you can use that to read memory that you shouldn’t be able to read."
Le operazioni che avvengono internamente ai processori Intel in materia di speculative execution, non eseguono il controllo sulla tipologia di informazioni presenti in cache, poichè non effettuano il distinguo tra memoria privilegiata e non nel lasso di tempo che intercorre tra il commit (quindi l'ultimo step) e l'inizio della nuova trafila. Pertanto è possibile scrivere codice che renda possibile accedere ad informazioni in memoria che non dovrebbero essere leggibili.
e poi ancora:
"The speculative prediction implementations of other CPU vendors don’t allow user-space applications to probe the contents of kernel space memory at any point"
L'implementazione della speculative execution da parte di altri produttori non consentono ad applicazioni in user-space di accedere ai contenuti della memoria protetta in nessuno punto, aggiungo quindi in nessuno step della trafila necessaria al completamento branch-prediction->speculative execution.