Localisation de faute à partir d'une trace d'exécution pour logiciel embarqué Mickaël Delahaye, Azzeddine Amiar, Lydie du Bousquet et Yliès Falcone Université Joseph Fourier-Grenoble I Laboratoire Informatique de Grenoble GDR GPL MTVV Saclay, 12 nov. 2012
Contexte : le projet IO32 Instrumentation et outil pour les microcontrôleurs 32 bits 3 PME grenobloises : AIM EASii-IC Trilogie 1 poids lourd du domaine STMicroelectronics et l'ujf 2
Qu'est-ce qu'un microcontrôleur? Circuit intégré qui rassemble sur une même puce les éléments essentiels d'un ordinateur : un processeur de la mémoire des entrées/sorties programmables (périphérique) Ils sont présents dans de nombreuses applications embarquées : électroménager, jouet, alarme, télécommande, machines outils, voiture, etc. Et ils sont très peu chers (par ex. un ARM Cortex M3 32 bits, ~5$ pièce)
Mais... Le coût du développement du logiciel qu'ils exécutent est bien plus important! IO32 vise à faciliter le développement de logiciel pour microcontrôleurs Nos partenaires explique ce coût par plusieurs facteurs : chaque application = un environnement quasi-unique (le microcontrôleur et ses périphériques) développement très bas niveau en C par conséquent, validation du logiciel très difficile en particulier le diagnostic des défaillances Quelques environnements de développement dédié (par ex. ARM KEIL), mais peu ou pas d'outil dédié à la validation (test ou vérification formelle)
Une difficulté et une opportunité La mise au point de logiciel pour les microcontrôleur est très difficile : le logiciel est enfoui dans un environnement unique à l'application, ce qui rend l'exécution difficile à simuler (voire impossible) encore aujourd'hui certaines vérifications du comportement du système se font à l'aide d'un oscilloscope Les nouvelles générations de puces intègrent des systèmes matériels permettant l'enregistrement d'une trace d'exécution à l'aide d'une sonde spécifique sans aucune données mais avec tout le flot de contrôle (en principe)
Une carte d'évaluation et sa sonde
Problèmes liées aux traces d'exécution Problème n 1 : volume de donnée Problème n 2 : répétabilité limitée Quelques minutes d'enregistrement représente des gigaoctets de données, impossible à analyser manuellement Un enregistrement de la défaillance oui, plusieurs enregistrements défaillant non Problème n 3 : coût élevé de la manipulation Brancher la sonde sur un système dans son environnement est très compliqué Bilan on ne le fait quand cas de défaillance donc pas de trace positive
Plan Contexte Compression Localisations de faute Conclusion et perspectives
Sequitur [Nevill-Manning et Witten, 1997] Algorithme en ligne efficace (en O(n)) Accepte une chaîne de caractère s en entrée Calcule une grammaire g en sortie avec la particularité que L(g) = { s } Exploite les répétitions et permet de retrouver des hiérarchies présentes dans les textes en langues naturelles, partitions de musique, etc.
Sequitur en action Entrée : cabcabcabcabcad S c deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S ca deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S cab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S cabc deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Répétition d'un digramme! S cabca deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Répétition d'un digramme! S cabca A ca deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S AbA A ca deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Répétition d'un digramme! S AbAb A ca deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S AbAb A ca B Ab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Sous-utilisation d'une règle! S BB A ca B Ab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S BB B cab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S BBc B cab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Répétition d'un digramme! S B B ca B cab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad S BBA A ca B Ab deux règles de construction : unicité des digrammes utilité des règles
Sequitur en action Entrée : cabcabcabcabcad Et ainsi de suite S CCAd A ca B Ab C BB deux règles de construction : unicité des digrammes utilité des règles Deux choses à noter : Compression irréductible mais non minimale Notations des répétitions consécutives artificielles et non optimales
Deux améliorations Exploiter les cycles présents dans les programmes embarqués la plupart des programmes pour microcontrôleur sont cycliques les cycles sont l'élément de base pour comprendre le comportement du programme il est intéressant de «forcer» la synchronisation sur les cycles pour obtenir une représentation plus compacte et plus utilisable Compresser efficacement les répétitions consécutives Le tout formalisé et implémenté (!)
Avec Cyclitur Entrée : cabcabcabcabcad Et ainsi de suite S c A⁴ B A abc B ad trois règles de construction : unicité des digrammes utilité des règles unicité des symboles consécutifs Compression irréductible mais non minimale Tout cycle est représentable par un unique symbole
Évaluation Appliquée aux traces de microcontrôleurs (25 de 100Mo et 5 de 4Go) taux de compression de l'ordre de 99,99% 1 millions de PC réduit à ~1000 symboles gain de 10-20% sur Sequitur Appliquée à des traces issues de captures de trafic réseau (5 de 4Go) avec des résultats comparables
Plan Contexte Compression Localisation de faute Conclusion et perspectives
Méthode «à base de spectre» [Jones, Harrold et Stasko, 2001] Collecter pour un ensemble de tests réussis et de tests en échec leur spectre* à l'exécution *un spectre est un ensemble d éléments capturés à l'exécution offrant une vue du comportement du a programme (e.g. une couverture) a +a 11 #n échec? 1 0 0 0 0 1 1 1 1 0 1 1 1 0 0 1 1 Lignes #1 #2 #3 T0 1 1 T1 1 T2 T3 0,75 Tar= 01 a 10 a 11 + a 00 +a 10 a 01 +a 11 Jac= Amp= Och= 11 a 11 a 11 +a 01 +a 10 a11 a10 a11 +a 01 a 10 +a00 a 11 (a11 +a01 ) (a10 +a00 )
Méthode du voisin le plus proche [Renieris et Reis, 2003] comparer les couvertures des tests réussis et d'un seul test en échec (à l'aide d'une distance ou d'un coefficient de similarité) sélectionner le test réussi qui a la couverture la plus similaire à au test défaillant appliquer les modèles intersection et union pour trouver les instructions suspectes
Dans notre contexte Un seule trace défaillante mais longue! Idée exploiter la présence des cycles chaque cycle est considéré comme une exécution indépendante hypothèse forte l'erreur est dans le dernier cycle
Accélérer la comparaison de cycles la comparaison de cycle peut être accélérée par la compression : distance de Hamming classique D Hamming (u,v )= u i v i +u i v i i estimation (ou calculée) en utilisant une sur-approximation D Hamming (u,v, w )= (u i v i + u i v i ) w i et sous-approximation D Hamming (u,v, w )= u i v i + u i v i i i sur une forme compressée des cycles u, v où chaque symbole i représente wi éléments de la trace la compression est dépliée jusqu'à ce que la différence relative entre sur- et sous-approximation passe sous un seuil
Accélérer la comparaison entre spectres et le vecteur d'erreur n comparaisons spectre/erreur sur m éléments n est le nombre d'éléments de couverture m est le nombre de «tests», ici de cycle deux stratégies : limiter n en considérant que des symboles issues de la compression dépliée jusqu'à une certaine profondeur limiter m en ne sélectionnant que les cycles les plus ressemblants au cycle défaillant au sens du voisin le plus proches
Évaluation (1) Benchmark 13 erreurs fournies par nos partenaires industriels représentantes d'erreurs difficile à diagnostiquer, notamment : dépassement/écrasement de pile/tas écriture dans une zone mémoire interdite 4 méthodes évaluées : voisin le plus proche méthode «à base de spectre» pour 4 coef. : Tarantula, Jaccard, Ochiai, Ample
Évaluation (2) Mesure Mesure de qualité d'un diagnostic automatique expense = nb. instr. inspéctées / nb. instr. exécutées où les instructions inspectées en descendant dans le classement ou en cas d'égalité en remontant dans le programme
Évaluation (3) Résultats la plupart en dessous de 10% sur programme réduit quelques cas problématiques lorsque l'hypothèse «dernier cycle fautif» est violée
Conclusion et perspectives Première approche complète de localisation de faute à partir d'une seule trace d'exécution d'un microcontrôleur exploite une compression de l'information adapte des techniques de localisation classiques Mais hypothèses fortes sur la cause de l'erreur expériences encore limitée Autres perspectives adapter et concevoir des méthodes de localisation plus avancées (fouille de données) exploiter le code et sa sémantique