Injection logicielle

Les outils d’injection logicielle injectent des fautes pendant l’exécution normale du système, en utilisant des mécanismes internes au système, comme le logiciel exécuté sur le système, les mécanismes intégrés de debug, de scan-chain ou d’accès direct à la mémoire (JTAG). En général, la méthode consiste à changer l’état du système dans la partie mémorisante (registres, RAM) ou à modifier le résultat d’un calcul (corruption d’un résultat, modification d’un message interne).

L’injection peut être faite à la compilation : le système est modifié pour émuler l’effet de la faute. On parle alors de mutation du système. Cela a l’avantage d’intégrer facilement la problématique des fautes dans le flot de conception existant puisqu’elles sont prises en compte par le système lui-même. Néanmoins, les fautes sont statiques puisqu’elles sont déterminées à la compilation.

L’autre possibilité est d’émuler la faute lors de l’occurence d’un évènement. La technique la plus simple utilise une temporisation pour injecter la faute à un mo- ment choisi à partir du début du déroulement du système. En utilisant les méca- nismes d’exception logicielle ou d’interruption matérielle, la faute peut être émulée lorsqu’une condition spécifique est remplie, par exemple lorsqu’une instruction par- ticulière est exécutée.

L’injection logicielle est attractive car elle permet de réduire le coût et de fournir une alternative de contrôle plus facile comparée aux techniques d’injection physiques qui exigent un équipement matériel spécial et des interfaces spécifiques au système cible. Par ailleurs, ces injections visent souvent l’application et éventuellement le système d’exploitation qui s’exécute sur le système cible, ce qui est difficile à effec- tuer en utilisant des techniques d’injections basées sur le matériel.

FERRARI est l’un des premiers outils d’injection de fautes émulant les effets des fautes physiques dans les programmes par des moyens logiciels. Xception a af- finé le modèle de fautes tout en ciblant le processeur plutôt que les programmes. EXFI a proposé des travaux qui permettent d’utiliser les fonctions du processeur au lieu de celles du système d’exploitation, ce qui permet d’utiliser des processeurs utilisés dans l’informatique embarqué. MAFALDA a permis de prendre en compte l’architecture des micro-noyaux et de tester à la fois les applications et le système d’exploitation face aux fautes.

FERRARI [KKA95] (Fault and ERRor Automatic Real-time Injector) a été créé à l’université d’Austin (Texas) par Kanawati, Kanawati et Abraham en 1992, pour évaluer la sûreté de fonctionnement de systèmes complexes en émulant des fautes matérielles par logiciel.

Il cible un programme sur la même machine que l’injecteur et utilise des déroute- ments (« trap ») matériels et logiciels pour injecter les fautes dans l’image mémoire au moment voulu.

Les fautes peuvent être temporaires ou permanentes et peuvent être injectées en mémoire avant le début du programme, après un certains nombre d’apparitions d’une adresse du segment de code ou au bout d’un certain temps. Il est possible de choisir la durée de la faute. Toutes les fautes sont émulées en logiciel.

Les fautes temporaires ont été déterminées à partir de modèles de fautes maté- rielles. Ces fautes temporaires peuvent être une erreur sur le compteur impliquant l’exécution d’une autre instruction, une erreur impliquant l’exécution de 2 instruc- tions, une erreur lors de la recherche d’une opérande de donnée, une erreur de sto- ckage d’une opérande, une erreur d’interprétation du code d’opération, une erreur

de chargement ou du stockage d’une opérande ou une erreur dans les drapeaux de condition.

Les fautes permanentes sont de 3 types : faute sur la ligne d’adresse (déplacement du compteur du programme), sur la ligne de donnée (changement de l’instruction) et faute sur le code de condition.

FERRARI peut aussi injecter des fautes dans le noyau du système d’exploitation en utilisant un processus privilégié.

Xception [CMS98] a été créé à l’université de Coimbra au Portugal en 1995, pour proposer un outil d’injection de fautes utilisant les fonctionnalités de debug et de surveillance des processeurs.

L’architecture d’Xception comporte un ordinateur hôte et un système cible. Xception est constitué de 3 modules : le module noyau (cible), le module d’ins- tallation des fautes (cible) et le module de gestion de test (hôte). Le module noyau est lié statiquement au noyau du système d’exploitation et contient les gestionnaires d’exceptions. Ce nouveau noyau doit être utilisé à la place du noyau normal pour réa- liser les expérimentations. Le module d’installation des fautes est une bibliothèque qui reçoit les paramètres de la machine hôte et les passe au noyau. Le module de gestion de test est localisé sur le système hôte et permet la définition des fautes injectées, le contrôle de l’expérimentation et la collection des résultats.

Les fautes considérées sont toutes temporaires, car forcer la valeur d’une variable pendant toute l’exécution est quelque chose de difficile. Elles peuvent avoir lieu dans la plupart des parties du processeur : Instruction Execution Control unit, Integer Unit, Floating Point Unit, Memory Management Unit, Internal Data Bus, Inter- nal Adress Bus, General Purpose Registers et Condition Code Register. Ces parties sont celles du modèle générique d’Xception, défini comme une interface commune aux processeurs utilisables avec Xception. Les fautes peuvent être injectées en utili- sant des triggers : opcode fetch, operand load, operand store, temps depuis le début ou une combinaison de ceux-ci. Elles peuvent être des stuck-at-0, des stuck-at-1, des bit-flips avec un masque de bits possibles (32 bits) ou des partages entre deux bits (« bridging »). Par exemple, on peut spécifiér une faute sur 3 bit-flips avec un masque 0x000000FF pour que les erreurs ne soient que sur les bits de poids faibles. EXFI [BPRR98] (EXception based Fault Injector) a été développé en 1998 à l’école polytechnique de Turin. Selon ses développeurs, ses principaux avantages sont qu’il est économique, portable et efficace.

EXFI est basé sur le Trace Exception Mode que l’on trouve dans les micropro- cesseurs. Il utilise exclusivement des exceptions pour injecter des fautes.

Par rapport à FERRARI, EXFI cible les microprocesseurs embarqués, plutôt que ceux de station de travail, ce qui l’amène à utiliser les capacités du microprocesseur et non celles du système d’exploitation. De plus, EXFI ne modifie par le code cible, ce qui le rend moins intrusif.

l’inverse d’Xception sur le processeur PowerPC. EXFI s’appuie sur le mécanismes de détection d’erreur (EDM du processeur) pour détecter un comportement erroné. EXFI injecte des bit-flips temporaires dans la mémoire (code & données) et dans les registres utilisateurs. L’approche peut être étendue aux collages, couplages, multiple bit-flips temporels et spatiaux, etc.

Le moment de la faute est exprimé en nombre d’instructions depuis le début de l’exécution de l’application.

MAFALDA [AFRS03] a été développé au LAAS-CNRS à Toulouse en 1999, dans le but de tester la robustesse et d’aider la conception des micro-noyaux. Il a été adapté pour les systèmes temps-réels [RAA02].

Pour injecter des fautes, MAFALDA intercepte les communications (appels de fonction,...) entre les processus et le micro-noyau pour pouvoir les modifier. L’injec- tion est pilotée par une machine hôte qui récupère les rapports (logs) des processus, de l’injecteur et du détecteur d’erreur.

MAFALDA injecte des bit-flips dans les paramètres utilisés dans l’utilisation des primitives du micro-noyau ou dans l’image mémoire du micro-noyau (segment de code ou de données), s’appuyant sur plusieurs études qui prouvent que ce modèle représente correctement les fautes physiques.

Comme elle ne nécessite pas de matériel spécifique, l’injection logicielle a connu un gros succès au milieu des années 90 : plus d’une dizaine d’outils entre 1992 et 1999 dont les principaux sont résumés dans le tableau 1.10.

L’injection logicielle émule les fautes physiques en modifiant l’état du système cible. Cette technique permet d’injecter des fautes dans des applications et des sys- tèmes d’exploitation, ce qui est plus difficile à concevoir avec des injections de fautes par matériel. Lors des campagnes d’injection, le système s’exécute à la même vitesse (ou presque) qu’en fonctionnement, ce qui permet de réaliser un grand nombre d’in- jections et de tester plusieurs modèles de fautes. De plus, l’injection logicielle ne nécessite aucun matériel dédié puisqu’elle réutilise les capacités fournies par le sys- tème à tester.

Cependant, les injections ne sont possibles que dans les endroits accessibles au logiciel. L’observabilité et la contrôlabilité sont donc parfois limitées. Les modifi- cations apportées au système peuvent conduire à des résultats erronés, comme des interférences au niveau du temps d’exécution, notamment lorsque le processus d’in- jection est ajouté au système.