Guidon Yann

Nous avons enfin défini une pile de contrôle protégée, rapide et sûre ! Il aura fallu trois articles pour y arriver mais il reste un goût d’inachevé, même d’inefficacité. Dans la grande tradition de Douglas Adams, voici donc le quatrième volet de la trilogie, où notre pile sera vraiment poussée à bout, capable de faire le café et plier votre linge. Enfin presque.

Dans les épisodes précédents, le « Single Stack Syndrome » a été décrit et poussé à son paroxysme en essayant (en vain) d’apprendre de nouveaux tours à GCC. Ensuite, après le « quoi », nous avons exploré le « pourquoi » de cette dystopie, tissée tout au long de l’histoire de l’informatique, du côté matériel comme logiciel. Devant une telle débâcle, c’est le moment ou jamais de garder ce qui marche et de faire l’inverse de ce qui ne va pas. Nous allons donc imaginer un « nouveau » type de pile qui pourrait trouver sa place dans de futurs microprocesseurs.

Lorsque l’on parle de programmation sécurisée, on pense d’abord à un dépassement d’indice d’un tableau ou à des droits d’accès non respectés, puisque ces aspects sont visibles par le programmeur. Par contre, la pile est sous le contrôle absolu du compilateur et le contrat implicite est que « ça fonctionne » tant que nous le laissons faire son travail, qui est de plus en plus alambiqué. L’article précédent [1] détaillait de façon lovecraftienne les soucis de flexibilité et de sécurité inhérents au modèle de programmation à une seule pile, utilisé par (quasiment) tous les compilateurs actuels. J’ai amalgamé tous ces problèmes dans le terme « Single Stack Syndrome », mais il n’y a pas que le C ou le x86 dans la vie ! Nous pouvons trouver des inspirations dans d’autres langages, d’autres architectures et d’autres ères.

Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.

Dans ma quête de « désinformatisation » [1], après avoir touché le fond en jouant avec des relais [2] (et sans en être remonté encore), j'ai sauté l'étape thermoïonique pour m'intéresser aux premiers transistors. Je me posais surtout cette question bête : comment nos aïeux ont-ils bien pu se débrouiller avec une technologie si capricieuse ?

« L’important ce n’est pas d’avoir raison, mais d’être compris » a dit Dominique de Villepin, un soir à la télé. Je ne suis pas diplomate, mais cet adage s’applique aussi parfaitement dans le domaine des sciences, et surtout des mathématiques et de ses applications, où la vérité absolue nous échappera toujours un peu (merci, Monsieur Gödel) et nos heuristiques comblent les lacunes. Avoir tort est inévitable quand on défriche un sujet totalement nouveau, la compréhension est alors indispensable pour compenser les petites erreurs ou zones d’ombre. Donc, ces derniers mois, je vous ai parlé en détail de checksums [1], de Galois et des corps finis [2] ou de générateurs de nombres pseudo-aléatoires [3] [4], ravivant avec succès une bien vieille série. Tout cela pour établir les bases du présent article, qui synthétise enfin PEAC : un générateur de séquences pseudo-aléatoires (PRNG), dérivé accidentel de la séquence de Fibonacci, aux propriétés fascinantes et aux applications très intéressantes.

Si vous lisez Hackable, c’est probablement parce que vous aimez tenir dans vos mains un objet qui est le résultat de votre travail, un symbole physique et tangible de votre ingéniosité, une récompense pour vos investissements, vos efforts et votre patience. Mais vous devrez lutter contre un ennemi bien plus puissant et dévastateur que l’obsolescence programmée, la crise économique, les délais de livraison, les composants douteux à des prix improbables, les aléas du traçage des colis ou le livreur qui ne sonne même pas à la porte. Cet ennemi est plus ancien et plus internalisé que la conjoncture socio-économique industrielle, et son unique solution pourrait vous faire passer pour un luddite ou un excentrique. Il ne tient qu’à vous de décider, et cette question cruciale n’est pas posée au bac philo : voulez-vous vraiment vous amuser, et accessoirement, à quel point est-il acceptable de se laisser enfermer dans un monde virtuel ?

Le benchmarking, ou mesure de la performance d’un morceau de code est devenu impossible alors qu’il reste absolument indispensable pour toute démarche d’optimisation. Comment peut-on savoir si une modification va l’accélérer, et dans quelle mesure ? Aujourd’hui, ce n’est en fait plus la vitesse absolue qui compte, mais la différence entre deux versions qui nous guidera.

La saga des PRNG (Pseudo-Random Number Generator en anglais) continue ! Le précédent article [1] a étudié la nature des séquences de nombres pseudo-aléatoires et tenté de classifier leurs applications. Il ne s’agissait pas de décrire un algorithme ou un système en particulier, mais d’en définir les propriétés essentielles et distinctives. Dans cette suite, nous allons plus loin en concevant un PRNG abstrait pour en déduire les caractéristiques « par construction », en s’appuyant sur les principes fondamentaux. Cela nous permettra plus tard de comprendre les défauts et qualités d’algorithmes concrets.