<div dir="auto">Salut<div dir="auto"><br></div><div dir="auto">Si jamais, la dernière émission de l'écho des gnous est un assez bon résumé de la situation  ! </div><div dir="auto"><br></div><div dir="auto">Manu</div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 21 janv. 2018 8:04 PM, "Yves Martin" <<a href="mailto:ymartin59@free.fr">ymartin59@free.fr</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2018-01-15 at 12:25 +0100, Marc Mongenet wrote:<br>
> Bonjour<br>
><br>
> Le 14 janvier 2018 à 21:46, Yves Martin <<a href="mailto:ymartin59@free.fr">ymartin59@free.fr</a>> a écrit :<br>
> >   Bonjour<br>
> ><br>
> > De ce que j'ai compris, la défaillance vient du fait que<br>
> > l'exécution<br>
> > anticipée se fait sans appliquer les contrôles de sécurité sur les<br>
> > accès mémoire.<br>
><br>
> Les contrôles sont effectués, sinon il n'aurait pas fallu tant de<br>
> temps<br>
> pour trouver les problèmes. Mais ils sont effectués après exécution<br>
> spéculative. Or l'exécution spéculative, comme toute exécution,<br>
> utilise les mémoires caches. Et elle peut donc causer le chargement<br>
> ou l'invalidation de lignes de de cache. En mesurant le temps d'accès<br>
> à des adresses bien choisies après l'exécution spéculative, il est<br>
> possible de reconstruire les données sur lesquelles il y a eu<br>
> spéculation.<br>
<br>
Ce problème de mesure des temps d'accès et d'exécution est connu depuis<br>
longtemps notamment en cryptanalyse lors des tests de robustesse des<br>
algorithmes sur des cartes à puce, avec en plus surveillance de la<br>
consommation... La nouveauté est d'appliquer cette technique<br>
d'inspection à un CPU classique.<br>
<br>
De mon point de vue, si les contrôles de sécurité sont appliquées avant<br>
les instructions même en exécution spéculative, les données en mémoire<br>
n'entreront plus dans le cache - puisque l'exécution spéculative est<br>
interrompue par exception/interruption.<br>
<br>
Je pense au microcode pour tenter de palier ces attaques car j'ai<br>
entendu parlé de problèmes de "fonderie" de lots de CPUs qui ont été<br>
contournés en désactivant par microcode les parties défectueuses, donc<br>
avec des performances moindres... Ces CPUs sont vendus au rabais mais<br>
cette méthode évite une perte sèche.<br>
<br>
--<br>
Yves Martin<br>
<br>
______________________________<wbr>_________________<br>
gull mailing list<br>
<a href="mailto:gull@forum.linux-gull.ch">gull@forum.linux-gull.ch</a><br>
<a href="http://forum.linux-gull.ch/mailman/listinfo/gull" rel="noreferrer" target="_blank">http://forum.linux-gull.ch/<wbr>mailman/listinfo/gull</a></blockquote></div></div>