Analyse statique incrémentale pour la vérification de programmes

Incremental Static Analysis for Program Verification

• Auteur / Autrice : Ny Andrianina Mamy Razafintsialonina
• Direction : Julien Signoles
• Type : Projet de thèse
• Discipline(s) : Informatique
• Date : Inscription en doctorat le 10/10/2022
• Etablissement(s) : université Paris-Saclay
• Ecole(s) doctorale(s) : École doctorale Sciences et technologies de l'information et de la communication
• Partenaire(s) de recherche : Laboratoire : Laboratoire d'intégration de systèmes et de technologies
• Partenaire(s) de recherche : Référent : Faculté des sciences d'Orsay

Mots clés

Mots clés libres

Analyse statique

Vérification de programmes

Interprétation abstraite

Analyse incrémentale

Abstract Interpretation

Program Verification

Static Analysis

Incremental Analysis

Résumé

Notre équipe développe Frama-C, une plateforme d'analyse de code C composée d'un ensemble d'analyseurs. Frama-C et ses greffons sont développés en OCaml. Cette plateforme permet à l'utilisateur d'annoter des programmes C avec des spécifications formelles écrites dans le langage de spécification ACSL. Frama-C peut garantir qu'un programme C vérifie sa spécification formelle à travers différentes techniques comme l'interprétation abstraite, le calcul de plus faible précondition ou la vérification d'assertion à l'exécution. Au sein de Frama-C, Eva est un plugin dédié à l'inférence automatique de propriété des programmes C et permet de trouver toutes les valeurs possibles de chaque variable ou encore les relations arithmétiques entre les variables. Le but premier de cette analyse est de prouver l'absence d'erreur à l'exécution (ex: les débordements arithmétiques, les accès mémoires invalides, n'importe quel autre comportement indéfini du C, ...). Il est également utilisée pour conduire de l'audit de code et comme support pour d'autres analyses. Il réalise une interprétation abstraite du programme qui a l'avantage d'être à la fois complètement automatique (aucune interaction avec l'utilisateur n'est nécessaire pendant l'analyse) et de passer à l'échelle. Dans un contexte industriel, il est souvent requis de réaliser ces analyses de manière incrémentale. Il y a deux cas d'utilisation (non exclusifs) d'une analyse incrémentale. 1. Pendant le développement d'un logiciel critique, des analyses peuvent être conduites pour détecter d'éventuels problèmes le plus tôt possible ou pour s'assurer que le logiciel sera facilement validé par ce genre d'analyses dès que la phase de validation débutera. La validation continue du logiciel nécessite un grand nombre d'analyses à exécuter entre chaque modification et le temps de calcul cumulé pourrait rendre la méthodologie impraticable. Dans ce contexte, il est également possible d'analyser les différences sémantiques impliquées par chaque modification. 2. Postérieurement au développement initial, une procédure de certification généralement réalisée par une équipe différente peut reposer sur une analyse complétée. Bien que cela ne requiert qu'une seule analyse, les expériences passées montrent qu'une telle analyse doit être finement réglée pour aboutir. En pratique, ce paramétrage est fait de manière incrémentale en ajustant les paramètres à chaque itération jusqu'à ce que l'outil parvienne à prouver l'absence d'erreur à l'exécution. Le coût de ce processus est d'un ordre de grandeur plus grand que le coût d'une analyse et risque d'être rédhibitoire. Il est crucial dans les deux scenarios que les analyses ultérieures coûtent considérablement moins que la première. Cependant la réutilisation de résultats précédents en interprétation abstraite est toujours un problème ouvert. Le but de ce sujet est d'explorer des solutions à ce problème et de les valider en les implantant dans la plateforme Frama-C. En particulier, cela inclut de la recherche sur - la catégorisation des changements dans le code source ou dans les paramètres de l'analyse et de leurs impacts sur l'analyse; - la conception de résumés d'analyse de fonction ou de fragments de code qui puissent être stockés sur disque et adéquat à la réutilisation; - la réutilisation d'invariants de boucle précédemment inférés pour accélérer la convergence des analyses postérieures; - la conception de stratégies d'itération plus adaptées à l'analyse incrémentale, en particulier dans le cas de la réutilisation de résumés ou d'invariants. Les solutions proposées seront implantées dans Eva mais devraient être suffisamment générales pour pouvoir être facilement adaptées à d'autres outils comme Mopsa et EACSL.

Our team develops Frama-C [1] (http://frama-c.com), a code analysis platform for C programs which provides several analyzers as plug-ins. Frama-C itself is developed in OCaml. Frama-C allows the user to annotate C programs with formal specifications written in the ACSL specification language [2]. Frama-C can then ensure that a C program satisfies its formal specification by relying on several techniques including abstract interpretation, weakest preconditions calculus, and runtime assertion checking. Inside Frama-C, Eva [3] is a plugin dedicated to the automatic inference of properties about C programs such as finding all the possible values of variables or inferring arithmetic relations between variables. The primary goal of this analysis is to prove the absence of runtime execution errors (e.g. arithmetic overflows, invalid memory accesses, other C undefined behaviors, ...). It is also used for code auditing and as a support for other analyses. It performs an abstract interpretation [4] of the program which has the advantage of being completely automatic (no user interaction is needed during the analysis) and scalable. In an industrial framework it is often required to run these analyses incrementally. There are two (overlapping) use cases of an incremental analysis. 1. During the development of a safety critical software, analyses can be run to detect flaws early or to ensure that the software will be easily validated with such analyses as soon as the validation phase starts. The continuous validation of the software will require numerous analyses to be run between each patch, and the cumulated computation cost might hinder the methodology. In this context, it is also possible to analyze the semantic differences induced by each patch [5]. 2. A certification process taking place after the initial development and usually by a distinct team can rely on a successful analysis. While this would require only one analysis, past experience shows that such an analysis would have to be finely tuned to achieve this goal. In practice, this tuning is done incrementally by adjusting the analysis parameters at each iteration until the tool succeeds in proving the absence of runtime errors. The cost of this process is one order of magnitude higher than the cost of one analysis and might be prohibitive. It is crucial in both scenarios that subsequent analyses cost considerably less than the first analysis. However, the reuse of previous results in abstract interpretation is still an open subject. The proposed solutions will be implemented in Eva, but should be general enough for being easily adapted to other tools such as Mopsa [6] and E-ACSL [7].