Analyse préliminaire

Le Tableau 4-6 illustre la distribution des résultats obtenus en considérant la stratégie du premier événement lorsque plusieurs événements sont relevés au cours de la même expérience.

En plus des événements spécifiques précédemment définis (voir Tableau 3-3), la table inclut également deux types de caractéristiques intéressantes :

- Non Activée (Not Act.): Les fautes injectées n’ont pas pu être activées. La charge de travail n’a pas activé la fonction sur laquelle la faute devait être injectée.

- Aucune Observation (No Obs.): Aucune notification d’événements et aucun mode de défaillance n’ont été observés alors que la faute a été activée.

Naturellement, quand la faute n’est pas activée, aucun événement particulier lié à la faute injectée ne peut être observé.

4.4.1.1 Les limites de l’observation

La proportion des expériences où les fautes n’ont pas été activées change de manière significative entre les pilotes et les versions de Linux; de 0% pour le pilote SB 2.2 à 17% pour le pilote SMC (Voir Tableau 4-6). 

Driver Not Act. No Obs. EC XC KH WA WI

SB 2.2 0% 18% 47% 22% 3% 1% 9%

SMC 2.2 7% 22% 19% 23% 21% 0% 9%

SMC 2.4 17% 17% 21% 34% 11% 0% 0%

NE 2.4 14% 10% 15% 30% 17% 0% 13%

Tableau 4-6 Distribution des observations en considérant le premier élément relevé Lorsque cette proportion est non nulle, cela peut signifier que les charges de travail respectives doivent être améliorées du point de vue de la testabilité afin de mieux contrôler les appels aux fonctions du noyau et en effectuer davantage. Cependant, ces taux sont très inférieurs à ceux qui sont rapportés dans d’autres études relatives au noyau Linux, comme dans [Gu et al. 2003].

Cette différence est due principalement à deux éléments. D’une part, dans notre cas, les fautes visent directement les paramètres des appels aux fonctions du noyau effectués par le pilote, au lieu du code exécutable correspondant au noyau. Toutes les parties d’un code exécutable ne sont pas utilisées par le processeur (par exemple à cause des structures répétitives et conditionnelles). D’autre part, les charges applicatives dédiées permettent une meilleure commandabilité des expériences en activant le pilote cible par les symboles que nous visons durant la campagne d’expériences.

L’interprétation des expériences sans observation (No Obs.) dépend étroitement du contexte spécifique où l’analyse est conduite. En effet, ces résultats peuvent être comptabilisés aussi bien comme étant positifs que négatifs, en fonction des points de vue correspondant à la notification d’événements, à la sûreté de la charge de travail ou encore à la disponibilité du noyau. Cependant, comme souvent dans toutes les approches expérimentales de ce type, des incertitudes demeurent toujours au sujet des véritables origines de ces résultats sans observation. En effet, l’outil d’injection de fautes peut être à l’origine de ce défaut de résultats, par un manque d’observation par exemple, ou une faute étrangère à notre système ayant affecté le système. Par conséquent, nous avons préféré adopter une approche conservatrice consistant à mettre à part ces résultats en vue d’analyses approfondies.

La deuxième exécution de la charge de travail a été mise en place pour réduire le nombre d’expériences sans observation et pour augmenter la confiance dans les interprétations effectuées. Une expérience privée de réaction du système indique dans certains cas une déficience de l’observation sur les expériences effectuées. Toutefois, il est fréquent que de tels résultats soient dus à des problèmes connexes difficiles à identifier :

- Le noyau n’a pas utilisé le paramètre corrompu, - Le paramètre corrompu n’a aucun impact sur le noyau,

- L’erreur provoquée est masquée (dans notre cas, le plus fréquent est l’injection d’une valeur 0 sur un paramètre déjà égal à 0).

Cependant, bien que le nombre d’expériences où aucune observation n’est effectuée est plus important que celui où la faute n’a pas été activée, les valeurs de ces deux catégories sont sensiblement inférieures à celles qui ont été présentées récemment dans [Gu et al. 2003].

Une autre cause possible de pénurie d’observation peut être une implémentation de mauvaise qualité de la fonction. Par exemple, dans certains symboles du noyau, si la valeur d’un paramètre testé est considérée comme invalide, la fonction interrompt son exécution sans renvoyer de code retour d’erreur. Ce type d’implémentation répond mal aux exigences de sûreté de fonctionnement, en particulier pour établir des diagnostics, car elle peut conduire à des erreurs dont l’origine est difficile à déterminer.

Nous avons vu plus haut dans ce paragraphe que l’erreur peut être masquée car la valeur d’origine est identique à la valeur corrompue. Ces cas de masquage peuvent être également dû à des paramètres de type « drapeaux », où seuls certains bits particuliers du paramètre sont testés par la fonction, les autres étant ignorés.

4.4.1.2 Premières analyses

La Figure 4-6 illustre la distribution relative des événements observés en utilisant le critère du premier événement relevé. Un examen rapide de ces résultats montre une proportion très basse d’interruption de la charge de travail pour toutes les expériences effectuées. En effet, l’impact des fautes injectées dans les pilotes est rarement observé au niveau de la terminaison d’une application. Le plus souvent le système aura déjà relevé une anomalie avant la propagation à la charge de travail conduisant à une terminaison brutale de celle-ci. C’est pourquoi les résultats indiquent qu’un grand pourcentage des fautes est détecté en premier par le noyau (ceci inclut les événements de code retour et les levées d’exception). Dans la pratique, il est intéressant de différencier les notifications correspondant aux exceptions et code retour d’erreur car ce dernier est préférable au premier. En effet, un code retour d’erreur indiquant un mauvais usage de la fonction est nécessaire pour effectuer une action de rétablissement réussie du système.

a) SB 2.2 b) SMC 2.2

c) NE 2.4 d) SMC 2.4

Figure 4-6 Distribution des premiers événements observés

En conséquence, il est possible d’affirmer que les résultats pour le pilote SB 2.2 sont meilleurs que ceux qui sont observés pour les expériences concernant les autres pilotes de carte réseau.

La comparaison des résultats obtenus par les pilotes SMC des deux versions du noyau indique clairement une amélioration de la robustesse en ce qui concerne la version 2.4. Elle est

marquée par l’augmentation de la couverture des exceptions lors de l’injection de faute dans les symboles du pilote. Une conséquence directe majeure est la forte diminution des blocages du noyau et des erreurs perçues au niveau de la charge de travail.

L’analyse avec priorité au premier événement collecté met en évidence que lorsqu’un événement de type « terminaison incorrecte » est observé en premier signifie qu’aucune autre notification n’a été relevée. Il est généralement le seul événement collecté lors de l’expérience, à moins qu’un blocage noyau soit relevé après la fin de la charge de travail (de tels cas sont rares). Dans la pratique, une analyse plus détaillée des données rassemblées est nécessaire pour s’assurer de ces relations. Nous verrons cela dans le cadre de l’analyse détaillée présentée à la fin de chapitre.