Owf 2013 rii panorama leroy

320 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
320
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Owf 2013 rii panorama leroy

  1. 1. Les outils de v´erification: `a la rescousse du logiciel fiable Xavier Leroy Inria Paris-Rocquencourt Rencontre Inria-industrie, 2013-10-04
  2. 2. La qualit´e du logiciel `a l’Inria De nombreux travaux sur diff´erentes facettes du probl`eme : G´enie logiciel : approches classiques (ing´eni´erie dirig´ee par les mod`eles) ou pas. Langages de programmation : langages fonctionnels (OCaml), langages r´eactifs, langages d´edi´es (domain-specific languages). V´erification et validation : les outils de v´erification formelle comme alternative au test (cet expos´e). Fondations : d´emonstration automatique (Alt-Ergo, VeriT), interactive (Coq) ; s´emantiques formelles de langages comme C, Javascript, . . .
  3. 3. Les domaines d’application Historiquement : le logiciel embarqu´e critique o`u sont en jeu des vies humaines (a´eronautique, ferroviaire) ou des int´erˆets ´economiques majeurs (cartes `a puce). En plein essort : le logiciel d’infrastructure syst`eme et r´eseaux (Linux, Windows, Apache, OpenSSL, . . . ). Demain ? des logiciels utilisateurs grand public (navigateurs Web, applis smartphones, applis Web) notamment pour la confidentialit´e et le respect de la vie priv´ee.
  4. 4. La v´erification M´ethode dominante aujourd’hui : le test (mˆeme `a de tr`es haut niveaux d’exigence, p.ex. DO-178). Une m´ethode qui atteint ses limites : • Exigences r´eglementaires : certaines normes requi`erent des garanties plus fortes (Crit`eres Communs niveau EAL7). • Difficult´es `a couvrir l’ensemble d’un logiciel complexe (notamment la bonne gestion des entr´ees erron´ees). • Coˆuts consid´erables pour construire la suite de tests et pour l’administrer.
  5. 5. V´erification et validation Que faire lorsque le test ne suffit plus ? R´eflexe de l’ing´enieur : utiliser des math´ematiques ! R´eflexe de l’informaticien : se faire aider par la machine ! → Les outils de v´erification formelle de code.
  6. 6. La v´erification formelle de logiciel ´Etablir des propri´et´es de sˆuret´e ou de s´ecurit´e du logiciel qui sont vraies • de toute ex´ecution possible du logiciel ; • pour toutes les valeurs possibles des entr´ees ; • sans ex´ecuter le logiciel ; • en temps fini et raisonnable. Deux exemples dans la suite : • Analyse statique de valeurs. • V´erification d´eductive (preuve de programmes). Les fondements de ces approches sont connus depuis longtemps (preuve de programmes : 1969 ; interpr´etation abstraite : 1977 ; model checking : 1981) mais c’est l’apparition r´ecente d’outils de v´erification qui les rend praticables.
  7. 7. L’analyse statique de valeurs Approximer (par un sur-ensemble) toutes les valeurs que peuvent prendre les variables et les cases m´emoire d’un programme pendant toutes ses ex´ecutions. En d´eduire que le programme n’a pas de comportement dangereux.
  8. 8. L’analyse statique de valeurs Approximer (par un sur-ensemble) toutes les valeurs que peuvent prendre les variables et les cases m´emoire d’un programme pendant toutes ses ex´ecutions. En d´eduire que le programme n’a pas de comportement dangereux.
  9. 9. 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]; // acc`es dans les bornes
  10. 10. Vraies et fausses alarmes Vraie alarme Fausse alarme (comportement dangereux) (analyse pas assez pr´ecise) Approximation plus fine (poly`edre au lieu de rectangle) : pas d’alarme
  11. 11. Propri´et´es garanties par analyse statique Principalement : l’absence d’erreurs `a l’ex´ecution. • Tableaux et pointeurs : • Pas d’acc`es hors-bornes. • Pas de d´er´ef´erencement du pointeur nul. • Pas d’acc`es apr`es un free ; pas de double free. • Contraintes d’alignement du processeur. • Entiers : • Pas de division par z´ero. • Pas de d´ebordements arithm´etiques. • Flottants : • Pas de d´ebordements arithm´etiques (infinis). • Pas d’op´erations ind´efinies (not-a-number).
  12. 12. Diff´erents types d’analyses de valeurs Analyses non-relationnelles : propri´et´es d’une seule variable. • De type num´erique : intervalle de variation x ∈ [a, b] ; congruences x mod N = 0. • De type pointeur : validit´e des acc`es m´emoire, non-aliasing entre pointeurs. Analyses relationnelles : invariants entre plusieurs variables. (Exemple : poly`edres = in´egalit´es lin´eaires ax + by ≤ c.) Analyses de propri´et´es non fonctionnelles : • Consommation m´emoire. • Temps d’ex´ecution (WCET). • Flots d’information.
  13. 13. Analyse de temps d’ex´ecution : aiT WCET
  14. 14. Quelques outils d’analyse statique Outils g´en´eralistes : • Coverity • MathWorks Polyspace verifier. • Frama-C value analyzer. Outils sp´ecialis´es `a un domaine d’application : • Microsoft Static Driver Verifier (code syst`eme Windows) • Astr´ee (codes de contrˆole-commande). • Fluctuat (analyse symbolique des erreurs en flottants). Outils op´erant sur le code machine apr`es compilation : • aiT WCET, aiT StackAnalyzer.
  15. 15. V´erification d´eductive (preuve de programmes) Annoter le programme avec des formules logiques : • Pr´econditions (exigences sur les arguments de fonctions) • Postconditions (garanties sur les r´esultats de fonctions) • Invariants de boucles. V´erifier que : • Pour chaque fonction, pr´econditions impliquent postconditions. • Pour chaque appel de fonction, les pr´econditions sont satisfaites. Outillage : • G´en´erateurs d’obligations de v´erifications. • D´emonstrateurs automatiques.
  16. 16. Exemple de v´erification d´eductive 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; }
  17. 17. Sp´ecification des pr´e- 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; @*/
  18. 18. Sp´ecification 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; }
  19. 19. Production et preuve des obligations
  20. 20. Comparaison analyse statique / v´erification d´eductive Analyse statique V´erification d´eductive Propri´et´es garanties Absence d’erreurs `a l’ex´ecution Propri´et´es fonctionnelles arbitrairement complexes Annotations manuelles Pas ou tr`es peu Beaucoup Passage `a l’´echelle 105–106 lignes 102–103 lignes
  21. 21. Outils et exemples Quelques outils de v´erification d´eductive : • Pour Java : KeYs • Pour C# : Spec# / Boogie • Pour C : Caveat, Frama-C / WP Quelques exemples de v´erifications d´eductives de grande taille : • L4.verified (NICTA, Australie) : v´erification du micro-noyau s´ecuris´e seL4 (8000 lignes). • CompCert (Inria) : v´erification d’un compilateur optimisant pour le langage C.
  22. 22. Conclusions Des fondations th´eoriques d´ej`a anciennes . . . . . . qui sont devenues praticables ces 10 derni`eres ann´ees. Une premi`ere g´en´eration d’outils disponible . . . . . . qui commencent `a ˆetre utilis´es pour le logiciel critique embarqu´e . . . et ne demandent qu’`a ˆetre essay´es dans d’autres domaines. Un domaine o`u l’industrie europ´eenne est en pointe. . . . . . et o`u la recherche acad´emique est tr`es active.
  23. 23. Quelques directions de travail Prise en compte du parall´elisme `a m´emoire partag´ee : • Analyse statique (absence de data races ; WCET). • V´erification d´eductive (logiques de s´eparation). • Formalisation des mod`eles m´emoires faibles impl´ement´es par les multicoeurs. Traiter d’autres langages que C & Java. V´erification fine des calculs flottants. Vers une v´erification formelle des outils de g´en´eration de code et de v´erification.

×