> 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.
Ce que tu décris, c'est Meltdown. > Ce qui me surprend, c'est que ceux-ci ne puisse être réintroduit dans > la partie "microcode" du processeur et donc mis à jour de façon > logicielle en passant par le BIOS... mais je dois avouer que je ne suis > pas à jour concernant la conception des CPUs modernes - ce serait bien > l'occasion de potasser. La partie microcode a des fonctionnalités restreintes. Les processeurs ARM n'en ont par exemple pas. Si Trump introduit une loi qui dit que 2+2=3 et qu'aucun juge n'invalide sa démarche, aucun fabricant de CPU ne pourra changer le calcul de l'adition, l'unité ALU (arithmetic and logic unit) est gravée dans le silicium comme une grosse partie du système de contrôle qui gère l'exécution spéculative. Seule solution ici, le patch logiciel mais sans solution centralisée: partout où l'on voit une addition, on teste si les deux opérandes sont 2 et 2 et on remplace l'addition de l'ALU par une affectation à 3. Mais il faut reprendre toutes les couches logicielles, ce qui veut dire qu'on a probablement intérêt à patcher au niveau source le kernel, recompiler et utiliser le chargement de code utilisateur en mémoire pour patcher le code binaire à la volée. Dom _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
