• [^] # Re: Attaques hardware

    Posté par . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 5.

    Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.

    Dans un ancien job, lorsque je codais encore avant de me mettre au pipeautron, j'avais eu un problème similaire.

    Les instructions qu'on utilisaient pour timer précisément les temps des fonction sur nos machines étaient très spécifiques (on faisait pas mal de choses avec des outils liés au parallélisme). Puis un jour, nos chiffres ont commencé à être un peu anormaux. Mais pas complètement faux, juste un peu faux. Genre comme si certains traitements avaient gagnés en vitesse par rapport à nos temps de référence. Quelqu'un s'en est rendu compte sur un gros coup de bol.

    Après pas mal de cheveux en moins (et de laborieux changements de version de tous les outils). J'ai fini par tomber sur le problème : la nouvelle version du compilateur s'amusait à déplacer une des instructions de timing qui faisait un "top" de "quelques" instructions. Forcément, ça toppait plus au bon moment, et certains traitement coûteux se retrouvaient non-comptabilisés.

    C'était la seule fois où j'ai du débugger au niveau machine de ma vie. C'était drôle.