La connerie de base, si j'ai bien compris, c'est que la prédiction de branchement déclenche le remplissage du cache, même si la lecture est interdite aux adresses de ses pages. Ensuite, une autre lecture mesurant un timing, permet de vérifier la présence en cache ou non de la donnée, ce qui donne une information sur sa valeur.
Pour que cela ne marche pas, il faut que les load spéculatifs fait sur des adresses interdites n'aient aucune différences de timing avec une page non lue dans l’exécution suivante. L'idéal serait de faire la vérification d’autorisation pendant l’exécution spéculative, dans l'ordre et non tout à la fin.
En gros, il ne faut pas qu'une exécution spéculative de code ou de data en provenance de zone interdite, puisse avoir un effet mesurable sur un code (comme le temps d'accès d'un load grâce au cache)
[^] # Re: Le rapport avec meltdown et spectre?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 4.
La connerie de base, si j'ai bien compris, c'est que la prédiction de branchement déclenche le remplissage du cache, même si la lecture est interdite aux adresses de ses pages. Ensuite, une autre lecture mesurant un timing, permet de vérifier la présence en cache ou non de la donnée, ce qui donne une information sur sa valeur.
Pour que cela ne marche pas, il faut que les load spéculatifs fait sur des adresses interdites n'aient aucune différences de timing avec une page non lue dans l’exécution suivante. L'idéal serait de faire la vérification d’autorisation pendant l’exécution spéculative, dans l'ordre et non tout à la fin.
En gros, il ne faut pas qu'une exécution spéculative de code ou de data en provenance de zone interdite, puisse avoir un effet mesurable sur un code (comme le temps d'accès d'un load grâce au cache)
"La première sécurité est la liberté"