Le carnet du grincheux

Vous le savez — ou vous ne le savez peut-être pas —, j'ai commis un petit logiciel de calcul intensif qui se trouve ici. Il s'agit d'un langage de programmation compact et efficace, peu gourmant en mémoire et qui cache tous les mécanismes de gestion de la mémoire aux utilisateurs sans passer par les ramasse-miettes souvent inefficaces comme ceux qui sont utilisés en Java ou qui peuvent être utilisés en C++. À moins que ce ne soit Java qui soit intrinsèquement mauvais. Mais je ne puis l'imaginer, autant de développeurs ne peuvent aujourd'hui se tromper.

Il y a une dizaine d'années, j'ai été contacté par le CERT pour corriger un problème de sécurité dans cet outil. Le CERT avait été mandaté par le JPL, émanation de la NASA, pour auditer mon code. Depuis, tous les ans, je reçois un rapport d'audit du CERT. J'ai reçu le dernier par courrier électronique pas plus tard que la semaine dernière.

Le CERT s'occupe de sécurité informatique. C'est très bien. À ce titre, le premier contact que j'ai eu avec eux était pour corriger un appel system() dans une routine en C, appel qui pouvait potentiellement être dangereux du point de vue de la stricte sécurité. J'ai remplacé cet appel par un popen(), ils étaient contents.

Or, dans leur dernier rapport, ils ne faisaient état d'aucun problème critique. Aucun problème critique, tu m'en diras tant. Le langage de programmation en question est conçu entre autre pour que le résultat soit le plus exact possible sur une machine à précision finie. En particulier, cela signifie que le type des données peut changer à la volée pour garantir le résultat. Il teste donc, entre autres, les dépassements sur les calculs effectués en entiers et convertit automatiquement le calcul en flottants s'il s'avère que le resultat ne peut être représenté en entier.

Et je suis tombé, j'en ai presque honte, sur le problème du débutant : faire l'hypothèque que l'étendue des nombres entiers représentables par une machine finie est symétrique par rapport à zéro. La conséquence de cette hypothèse un peu hasardeuse est que j'ai codé la valeur absolue et la négation unaire brutalement avec un signe moins, ainsi que la soustraction comme une addition avec l'opposé du second argument.

Sauf que cette étendue n'est pas symétrique. Pour fixer les idées, si je travaille sur un processeur de huit bits, je peux représenter tous les entiers entre -128 et… +127. L'opposé de 127 peut être représenté sur ces huit bits. Mais qu'en est-il de l'opposé de -128 ? En complément à deux, très majoritaire sur les processeurs actuels, l'opposé de -128 fait -128. Dans toutes les opérations arithmétiques sur des entiers utilisant de près ou de loin une opposition, il y avait donc un entier qui provoquait un dépassement de capacité non traité et donc un résultat erroné. Il fallait que l'un des arguments de la commande ou qu'un calcul intermédiaire utilise la valeur -(2⁶³), ce qui était tout de même très rare, mais c'était tout à fait possible.

Le CERT a donc validé un code gravement erroné parce qu'il n'avait pas de faille de sécurité. J'espère au moins que cet audit de sécurité est sérieux. Le code étant utilisé par le JPL, pourvu que je ne sois pas responsable d'un problème de trajectoire d'une sonde spatiale…