On Mon, 2018-01-15 at 12:25 +0100, Marc Mongenet wrote: > Bonjour > > Le 14 janvier 2018 à 21:46, Yves Martin <[email protected]> a écrit : > > Bonjour > > > > De ce que j'ai compris, la défaillance vient du fait que > > l'exécution > > anticipée se fait sans appliquer les contrôles de sécurité sur les > > accès mémoire. > > Les contrôles sont effectués, sinon il n'aurait pas fallu tant de > temps > pour trouver les problèmes. Mais ils sont effectués après exécution > spéculative. Or l'exécution spéculative, comme toute exécution, > utilise les mémoires caches. Et elle peut donc causer le chargement > ou l'invalidation de lignes de de cache. En mesurant le temps d'accès > à des adresses bien choisies après l'exécution spéculative, il est > possible de reconstruire les données sur lesquelles il y a eu > spéculation.
Ce problème de mesure des temps d'accès et d'exécution est connu depuis longtemps notamment en cryptanalyse lors des tests de robustesse des algorithmes sur des cartes à puce, avec en plus surveillance de la consommation... La nouveauté est d'appliquer cette technique d'inspection à un CPU classique. De mon point de vue, si les contrôles de sécurité sont appliquées avant les instructions même en exécution spéculative, les données en mémoire n'entreront plus dans le cache - puisque l'exécution spéculative est interrompue par exception/interruption. Je pense au microcode pour tenter de palier ces attaques car j'ai entendu parlé de problèmes de "fonderie" de lots de CPUs qui ont été contournés en désactivant par microcode les parties défectueuses, donc avec des performances moindres... Ces CPUs sont vendus au rabais mais cette méthode évite une perte sèche. -- Yves Martin _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
