Upload
patrick-moreau
View
123
Download
0
Embed Size (px)
Citation preview
Les outils de verification:a la rescousse du logiciel fiable
Xavier Leroy
Inria Paris-Rocquencourt
Rencontre Inria-industrie, 2013-10-04
La qualite du logiciel a l’Inria
De nombreux travaux sur differentes facettes du probleme :
Genie logiciel :approches classiques (ingenierie dirigee par les modeles) ou pas.
Langages de programmation :langages fonctionnels (OCaml), langages reactifs, langages dedies(domain-specific languages).
Verification et validation :les outils de verification formelle comme alternative au test(cet expose).
Fondations :demonstration automatique (Alt-Ergo, VeriT), interactive (Coq) ;semantiques formelles de langages comme C, Javascript, . . .
Les domaines d’application
Historiquement : le logiciel embarque critiqueou sont en jeu des vies humaines (aeronautique, ferroviaire)ou des interets economiques majeurs (cartes a puce).
En plein essort : le logiciel d’infrastructure systeme et reseaux(Linux, Windows, Apache, OpenSSL, . . . ).
Demain ? des logiciels utilisateurs �grand public�
(navigateurs Web, applis smartphones, applis Web)notamment pour la confidentialite et le respect de la vie privee.
La verification
Methode dominante aujourd’hui : le test(meme a de tres haut niveaux d’exigence, p.ex. DO-178).
Une methode qui atteint ses limites :
• Exigences reglementaires : certaines normes requierent desgaranties plus fortes (Criteres Communs niveau EAL7).
• Difficultes a �couvrir� l’ensemble d’un logiciel complexe(notamment la bonne gestion des entrees erronees).
• Couts considerables pour construire la suite de tests et pourl’administrer.
Verification et validation
Que faire lorsque le test ne suffit plus ?
Reflexe de l’ingenieur : utiliser des mathematiques !
Reflexe de l’informaticien : se faire aider par la machine !
→ Les outils de verification formelle de code.
La verification formelle de logiciel
Etablir des proprietes de surete ou de securite du logiciel qui sontvraies
• de toute execution possible du logiciel ;
• pour toutes les valeurs possibles des entrees ;
• sans executer le logiciel ;
• en temps fini et raisonnable.
Deux exemples dans la suite :
• Analyse statique de valeurs.
• Verification deductive (preuve de programmes).
Les fondements de ces approches sont connus depuis longtemps(preuve de programmes : 1969 ; interpretation abstraite : 1977 ;model checking : 1981) mais c’est l’apparition recente d’outils deverification qui les rend praticables.
L’analyse statique de valeurs
Approximer (par un sur-ensemble) toutes les valeurs que peuventprendre les variables et les cases memoire d’un programme pendanttoutes ses executions.
En deduire que le programme n’a pas de comportement dangereux.
L’analyse statique de valeurs
Approximer (par un sur-ensemble) toutes les valeurs que peuventprendre les variables et les cases memoire d’un programme pendanttoutes ses executions.
En deduire que le programme n’a pas de comportement dangereux.
Exemple d’analyse statique
unsigned char entrees[10];
double table[256];
int i, somme, moyenne;
somme = 0;
for (i = 0; i < 10; i++) {somme += entrees[i]; // somme ∈ [0, 2550]
}moyenne = somme / 10; // moyenne ∈ [0, 255]return table[moyenne]; // acces dans les bornes
Vraies et fausses alarmes
Vraie alarme Fausse alarme(comportement dangereux) (analyse pas assez precise)
Approximation plus fine (polyedre au lieu de rectangle) :pas d’alarme
Proprietes garanties par analyse statique
Principalement : l’absence d’erreurs a l’execution.
• Tableaux et pointeurs :• Pas d’acces hors-bornes.• Pas de dereferencement du pointeur nul.• Pas d’acces apres un free ; pas de double free.• Contraintes d’alignement du processeur.
• Entiers :• Pas de division par zero.• Pas de debordements arithmetiques.
• Flottants :• Pas de debordements arithmetiques (infinis).• Pas d’operations indefinies (not-a-number).
Differents types d’analyses de valeurs
Analyses �non-relationnelles� : proprietes d’une seule variable.
• De type numerique : intervalle de variation x ∈ [a, b] ;congruences x mod N = 0.
• De type pointeur : validite des acces memoire, non-aliasingentre pointeurs.
Analyses relationnelles : invariants entre plusieurs variables.(Exemple : polyedres = inegalites lineaires ax + by ≤ c .)
Analyses de proprietes �non fonctionnelles� :
• Consommation memoire.
• Temps d’execution (WCET).
• Flots d’information.
Analyse de temps d’execution : aiT WCET
Quelques outils d’analyse statique
Outils �generalistes� :
• Coverity
• MathWorks Polyspace verifier.
• Frama-C value analyzer.
Outils specialises a un domaine d’application :
• Microsoft Static Driver Verifier (code systeme Windows)
• Astree (codes de controle-commande).
• Fluctuat (analyse symbolique des erreurs en flottants).
Outils operant sur le code machine apres compilation :
• aiT WCET, aiT StackAnalyzer.
Verification deductive(preuve de programmes)
Annoter le programme avec des formules logiques :
• Preconditions (exigences sur les arguments de fonctions)
• Postconditions (garanties sur les resultats de fonctions)
• Invariants de boucles.
Verifier que :
• Pour chaque fonction, preconditions impliquentpostconditions.
• Pour chaque appel de fonction, les preconditions sontsatisfaites.
Outillage :
• Generateurs d’obligations de verifications.
• Demonstrateurs automatiques.
Exemple de verification deductive
Recherche dichotomique dans une table.
int binary_search(long t[], int n, long v) {
int l = 0, u = n-1;
while (l <= u) {
int m = l + (u - l) / 2;
if (t[m] < v)
l = m + 1;
else if (t[m] > v)
u = m - 1;
else return m;
}
return -1;
}
Specification des pre- et post-conditions
Dans le langage ACSL de l’outil Frama-C :
/*@ requires n >= 0 && \valid_range(t,0,n-1);
@ behavior success:
@ assumes // array t is sorted in increasing order
@ \forall integer k1, k2;
@ 0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];
@ assumes // v appears somewhere in the array t
@ \exists integer k; 0 <= k <= n-1 && t[k] == v;
@ ensures 0 <= \result <= n-1 && t[\result] == v;
@ behavior failure:
@ assumes // v does not appear anywhere in the array t
@ \forall integer k; 0 <= k <= n-1 ==> t[k] != v;
@ ensures \result == -1;
@*/
Specification de l’invariant de boucle
int binary_search(long t[], int n, long v) {
int l = 0, u = n-1;
/*@ loop invariant 0 <= l && u <= n-1;
@ for success:
@ loop invariant
@ \forall integer k;
@ 0 <= k < n && t[k] == v ==> l <= k <= u;
@ loop variant u-l;
@*/
while (l <= u) {
int m = l + (u - l) / 2;
if (t[m] < v)
l = m + 1;
else if (t[m] > v)
u = m - 1;
else return m;
}
return -1;
}
Production et preuve des obligations
Comparaison analyse statique /verification deductive
Analyse statique Verification deductive
Proprietesgaranties
Absence d’erreursa l’execution
Proprietes fonctionnellesarbitrairement complexes
Annotationsmanuelles
Pas ou tres peu Beaucoup
Passage a l’echelle 105–106 lignes 102–103 lignes
Outils et exemples
Quelques outils de verification deductive :
• Pour Java : KeYs
• Pour C# : Spec# / Boogie
• Pour C : Caveat, Frama-C / WP
Quelques exemples de verifications deductives de grande taille :
• L4.verified (NICTA, Australie) :verification du micro-noyau securise seL4 (8000 lignes).
• CompCert (Inria) :verification d’un compilateur optimisant pour le langage C.
Conclusions
Des fondations theoriques deja anciennes . . .
. . . qui sont devenues praticables ces 10 dernieres annees.
Une premiere generation d’outils disponible . . .
. . . qui commencent a etre utilises pour le logiciel critique embarque
. . . et ne demandent qu’a etre essayes dans d’autres domaines.
Un domaine ou l’industrie europeenne est en pointe. . .
. . . et ou la recherche academique est tres active.
Quelques directions de travail
Prise en compte du parallelisme a memoire partagee :
• Analyse statique (absence de data races ; WCET).
• Verification deductive (logiques de separation).
• Formalisation des modeles memoires �faibles� implementespar les multicoeurs.
Traiter d’autres langages que C & Java.
Verification fine des calculs flottants.
Vers une verification formelle des outils de generation de code etde verification.