Quand on travaille avec de grandes quantités de bits, on n’a pas forcément envie de faire une interface graphique, et les afficher dans le terminal graphique n’est pas facile. Un bit occupe toute la place d’un caractère et la représentation hexadécimale n’est pas très parlante. Heureusement, Unicode est là !
Qu’est-ce qui caractérise un langage de haut niveau ? On peut dire que celui-ci doit au moins gérer les chaînes de caractères facilement et sans aucun risque. BASIC le faisait il y a soixante ans. N’importe quel langage courant le fait actuellement. Pourtant, le précédent article a démont(r)é [1] que le C n’en fait pas partie, surtout à cause des fonctions printf(3) et assimilées : elles procurent une illusion d’aisance qui s’effondre vite et c’est un vrai nid à failles. Nous avons suggéré quelques solutions que nous allons mettre en œuvre ici, grâce notamment au format des chaînes alignées [2] étendu avec des attributs, d’où le nom aStrA. Cela demande un peu de bricolage pour les réaliser en C, mais c’est un premier pas en avant, une base qui ne demande qu’à évoluer.
L’exploration des algorithmes PEAC et de leurs applications se poursuit ! Le précédent article [1] avait abouti sur une fonction de checksum ultrarapide pour calculer l’empreinte d’un fichier. Cette fois-ci, nous irons plus loin en décortiquant d’autres réalisations pratiques, certaines complémentant les LFSR et d’autres les supplantant. Un petit tour du côté de POSIX nous rappellera qu’il est temps de tourner la page. Nous en profiterons même pour tâter un peu de VHDL : l’algorithme PEAC peut aussi sortir du monde logiciel ! On commence ici à s’approcher d’un « cookbook ».
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.
