> 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.
Le microcode ne permet que des changements partiels dans l'exécution. Les chemins d'accès aux caches, par exemple, sont fixes (position, largeur). L'ajout du microcode coûte du temps de cycle, on l'utilise donc avec parcimonie et on évite que tout le processeur soit contrôlé par la cache, car cela le rendrait plus lent. C'est ce qui est difficile ici. On doit attaquer le problème indirectement et c'est ce qui pose problème aux constructeurs de CPU. Comment utiliser un ensemble restreint d'instructions microcodes pour affecter l'exécution d'une partie non accessible par ces mêmes instructions. Sinon, il y a déjà des mois qu'intel et AMD auraient sorti des patches. Dom _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
