Guidon Yann

Je rêve d’un jour où la sécurité ne sera plus une option. J’ai donc commencé à mettre au point le modèle CDI [1] [2] : une architecture Harvard modifiée qui dédie un troisième espace d'adressage indépendant pour la pile de contrôle. Ce n'est pas la solution à tous les problèmes, mais ça y contribue beaucoup ! Pour preuve, un exploit récent divulgué à pwn2own [3] aurait facilement été stoppé par ce mécanisme. Mais cet exploit me sidère par son vecteur d'attaque que j’ignorais jusque-là : l'incontournable printf(3). Quand votre librairie standard inclut l’équivalent d’une machine de Turing, pour dynamiquement parser ou afficher du texte, ce n'est plus de l’idiosyncrasie mais de l'idiotie.

Du 19 au 21 juin a eu lieu la FSiC2024 [1], ou « Free Silicon Conference » sur le campus de Jussieu à Paris : trois intenses journées organisées par le projet « Go IT ! » (financé par l’Union européenne [2]) et hébergées par le département LIP6 de la Sorbonne/Paris 6. On y a croisé des académiques, bien sûr, mais aussi des bricoleurs de différents niveaux et d’horizons variés, des industriels et même des institutionnels ! Voici un petit résumé de ce que vous avez manqué et pourquoi vous auriez dû venir.

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 ?

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.