Pourquoi analyser les OS est difficile, et comment je l’ai fait.
Cette thèse est consacrée à l’analyse de logiciels de bas niveau, tels que les systèmes d’exploitation, par interprétation abstraite. L’analyse des OS est une question importante pour garantir la sûreté des systèmes logiciels puisqu’ils forment le niveau immédiatement au dessus du matériel et que toutes les tâches applicatives dépendent d’eux. Pour des applications critiques, on veut s’assurer que l’OS ne plante pas, mais aussi qu’il assure l’isolation des programmes, de sorte qu’un programme dont la fiabilité n’a pas été établie ne puisse perturber un programme de confiance. L’analyse de ce genre de programmes soulève des problèmes spécifiques. Cela provient du fait que les OS doivent contrôler le matériel avec des opérations qui n’ont pas de sens dans un programme ordinaire. De plus, comme les fonctionnalités matérielles sont en dehors du for du C, le code source contient des blocs de code assembleur mêlés au C. Ce sont les deux axes de cette thèse : gérer les mélanges de C et d’assembleur, et abstraire finement les opérations spécifiques aux logiciels de bas niveau. Ce travail est guidé par l’analyse d’un cas d’étude d’un partenaire industriel, ce qui a nécessité l’implémentation des méthodes proposées dans l’analyseur statique Astrée. La première partie s’intéresse à la formalisation d’un langage mélangeant des modèles simplifiés du C et de l’assembleur, depuis la syntaxe jusqu’à la sémantique. Cette spécification est importante pour définir ce qui est légal et ce qui constitue une erreur, tout en tenant compte de la complexité des interactions du C et de l’assembleur, tant en termes de données que de flot de contrôle. La seconde partie est une introduction sommaire à l’interprétation abstraite qui se limite à ce qui est utile par la suite. La troisième partie propose une abstraction de la sémantique des mélanges de C et d’assembleur. Il s’agit en fait d’une collection d’abstractions paramétriques qui gèrent chacun des aspects de cette sémantique. La quatrième partie s’intéresse à l’abstraction des opérations spécifiques aux logiciels de bas niveau. Les propriétés d’intérêt peuvent être facilement prouvées à l’aide de variables fantômes, mais pour des raisons techniques, il est difficile de concevoir un produit réduit de domaines abstraits qui supporte une gestion satisfaisante des variables fantômes. Cette partie construit un tel cadre très général ainsi que des domaines qui permettent de résoudre beaucoup de problèmes dont le nôtre. L’ultime partie présente quelques propriétés à prouver pour garantir l’isolation des programmes, qui n’ont pas été traitées car elles posent de nouvelles et complexes questions. On donne aussi quelques propositions d’amélioration du produit de domaines avec variables fantômes introduit dans la partie précédente, tant en termes de fonctionnalités que de performances.