Pour ce que j'ai lu de la même page, c'est PRESQUE cela, en effet, mais à quelques détails près et qui feraient, entre autres, que l'approche par indexation en particulier ne pourrait justement pas marcher. Par ailleurs, tout repose sur le fait que l'on mesure un temps d'accès pour savoir si une donnée est ou non dans le cache. Et comme la réponse à cette question est forcément « oui » ou « non », ça implique de distiller l'info bit par bit, d'où l'exemple de la page Wikipédia et de son bit 0.
En gros :
On flushe le cache à deux adresses légitimes mais différentes et qui, selon moi, doivent également correspondre à deux pages de cache DISTINCTES, donc relativement éloignées l'une de l'autre (d'où le problème avec l'indexation) ;
On lit la valeur d'une adresse « hors zone » dans un registre R ;
On laisse volontairement le programme segfaulter à cause de cela (on rattrapera le problème avec un handler de signal) ;
On continue ensuite comme si de rien n'était, en extrayant de R le bit qui nous intéresse et en faisant un calcul pour résulter, selon sa valeur, à l'une ou l'autre des adresses légitimes évoquées au départ ;
On lit le contenu de l'adresse calculée ;
On lit le contenu les contenus respectifs de ces deux adresses en mesurant le temps que cela prend (par exemple, avec RDTSC, j'imagine).
La page précise qu'il vaut mieux éviter les branchement conditionnels pour faire ces calculs pour éviter de mettre en branle les mêmes mécanismes prédictifs (en gros, faire le calcul avec des opérateurs logiques plutôt qu'avec des « if »).
On se moque, en fait, de ce que contiennent les deux adresses légitimes mais toute l'astuce s'appuie sur le fait que la segfault va prendre un certain temps pour être déclenchée, et que les points 3, 4 et 5 auront le temps d'être honorés même si le CPU fait marche arrière ensuite si elle l'est. Après, sachant qu'on avait au départ vidé le cache, le point numéro 5 l'aura rechargé quand même. Donc, si l'une des pages est lente à accéder et que l'autre est rapide, on peut en déduire la valeur du bit recherché.
Évidemment, c'est très sioux et tout le problème réside dans le fait que ce n'est pas du tout un problème algorithmique. Tout microprocesseur doté d'un système de protection, d'un mécanisme de prédiction ET utilisant de la mémoire cache est potentiellement affecté.
On pourrait déjà circonvenir au problème en invalidant TOUT le cache en cas de segfault, mais on pourrait encore contourner la chose en faisant lire les adresses concernées par un thread ou un processus distinct qui, lui, n'aurait rien à se reprocher. Et qui pourrait presque le faire, en le synchronisant bien, avant le déclenchement de la segfault. C'est déjà compliqué à gérer en soi, mais ça devient particulièrement gênant sur les multicœurs et les systèmes distribués.
Et là où ça devient vraiment désespérant, c'est qu'apparemment la solution envisagée est : « puisque c'est une faille qui s'appuie sur la mesure des performances, alors on va sacrifier les performances ».
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
Pour ce que j'ai lu de la même page, c'est PRESQUE cela, en effet, mais à quelques détails près et qui feraient, entre autres, que l'approche par indexation en particulier ne pourrait justement pas marcher. Par ailleurs, tout repose sur le fait que l'on mesure un temps d'accès pour savoir si une donnée est ou non dans le cache. Et comme la réponse à cette question est forcément « oui » ou « non », ça implique de distiller l'info bit par bit, d'où l'exemple de la page Wikipédia et de son bit 0.
En gros :
La page précise qu'il vaut mieux éviter les branchement conditionnels pour faire ces calculs pour éviter de mettre en branle les mêmes mécanismes prédictifs (en gros, faire le calcul avec des opérateurs logiques plutôt qu'avec des « if »).
On se moque, en fait, de ce que contiennent les deux adresses légitimes mais toute l'astuce s'appuie sur le fait que la segfault va prendre un certain temps pour être déclenchée, et que les points 3, 4 et 5 auront le temps d'être honorés même si le CPU fait marche arrière ensuite si elle l'est. Après, sachant qu'on avait au départ vidé le cache, le point numéro 5 l'aura rechargé quand même. Donc, si l'une des pages est lente à accéder et que l'autre est rapide, on peut en déduire la valeur du bit recherché.
Évidemment, c'est très sioux et tout le problème réside dans le fait que ce n'est pas du tout un problème algorithmique. Tout microprocesseur doté d'un système de protection, d'un mécanisme de prédiction ET utilisant de la mémoire cache est potentiellement affecté.
On pourrait déjà circonvenir au problème en invalidant TOUT le cache en cas de segfault, mais on pourrait encore contourner la chose en faisant lire les adresses concernées par un thread ou un processus distinct qui, lui, n'aurait rien à se reprocher. Et qui pourrait presque le faire, en le synchronisant bien, avant le déclenchement de la segfault. C'est déjà compliqué à gérer en soi, mais ça devient particulièrement gênant sur les multicœurs et les systèmes distribués.
Et là où ça devient vraiment désespérant, c'est qu'apparemment la solution envisagée est : « puisque c'est une faille qui s'appuie sur la mesure des performances, alors on va sacrifier les performances ».