DBench

Les travaux de DBench sur les systèmes d’exploitation concernent deux aspects complémentaires : 1) la représentativité des fautes, et 2) l’étalonnage de la sûreté de fonctionnement de systèmes d’exploitation à base de micro-noyaux et à usage général vis- à-vis de pilotes de périphériques ou de l’application.

Représentativité des fautes

Pour étudier la représentativité des fautes dans les systèmes d’exploitation, les travaux présentés dans [Jarboui 2002a] ont visé à analyser le degré de similitude des comportements erronés des noyaux, suite à l’injection des différents modèles de fautes. Ces études ont ciblé le noyau Linux 2.4.0. Un modèle de fautes est défini par rapport au type de faute et au lieu d’injection. Les types de fautes peuvent être soit des bit-flips (comme dans MAFALDA), soit des corruptions sélectives des paramètres (comme dans BALLISTA). Quant au lieu, l’injection peut avoir lieu au niveau des appels système, c’est-à-dire au niveau de l’API, ou sur les paramètres des fonctions internes du noyau.

Les fautes au niveau de l’API simulent les fautes des applications et sont utilisées pour tester la robustesse du noyau en présence d’applications erronées. Les substitutions sélective et systématique des paramètres ont été utilisées pour corrompre les paramètres des appels système. Des activités modulaires ont été développées pour activer le système à

1.5 Caractérisation des systèmes d’exploitation

30

caractériser, et en particulier, deux modules fonctionnels de base : l’ordonnancement et la gestion de mémoire.

La comparaison des deux modèles de substitution est accomplie à partir de la comparaison de leurs effets respectifs sur le noyau. Le niveau d’observation le plus élevé est l’observation des défaillances. Si les défaillances observées après l’injection de deux modèles de fautes sont différentes alors elles ne sont pas considérées comme équivalentes. Cependant, si les défaillances observées sont similaires, alors un raffinement de ces observations peut être utile pour analyser plus finement le comportement.

Les auteurs ont groupé les défaillances des systèmes d’exploitation en deux classes : « défaillances rapportées » et « défaillances non rapportées ». Les défaillances rapportées englobent les cas où une exception est levée ou un code d’erreur est retourné. Dans le cas des défaillances non rapportées, on distingue le gel de l’application ou du noyau. Si aucun de ces cas n’a été observé, le mode de défaillance est appelé « non-signalement ».

Les résultats obtenus montrent que les deux types de fautes provoquent les mêmes modes de défaillance en nature et en quantité. En effet, le mode dominant de défaillance était le code d’erreur retourné (57% pour la substitution sélective et 45% pour les bit-flips). Les modes de défaillance non rapportée étaient pratiquement équivalents. La substitution sélective a provoqué moins de cas de non-signalement (28% des cas pour la substitution sélective contre 42% pour les bit-flips).

Ces résultats ont été raffinés en considérant d’autres critères comme la nature du code d’erreur retourné, la propagation des erreurs… Les résultats obtenus montrent que les bit- flips sont meilleurs en termes de la facilité d’application et de la diversification des codes d’erreur retournés tandis que la substitution sélective est meilleure en termes de durée d’expérimentation et de propagation d’erreurs.

En plus de l’injection des fautes au niveau de l’interface noyau-application, [Jarboui 2002a] présente les résultats de la substitution systématique des valeurs des paramètres des fonctions internes du noyau Linux. Les résultats obtenus montrent qu’un code d’erreur est retourné dans seulement 2% des expériences, alors que dans 28% des cas, une exception est levée, ce qui veut dire que 30% des fautes injectées ont donné lieu à des détections des erreurs. 32% des expériences ont provoqué des gels de l’application ou du noyau.

Etalonnage vis-à-vis des pilotes de périphériques

De part leur proximité du noyau et leurs origines diversifiées, les pilotes de périphérique ont un impact significatif sur la sûreté de fonctionnement du système global. Les travaux de [Albinet 2004] présente une méthodologie pour évaluer la robustesse des interfaces des systèmes d’exploitation vis-à-vis de pilotes défaillants. Ils proposent de simuler des erreurs résiduelles dans le code correspondant aux pilotes par injection de fautes par logiciel pendant l’exécution. Les observations consistent à relever les modes de défaillance du système d’exploitation en présence de ces erreurs. Pour réaliser les expériences, une interface de programmation pilote-noyau DPI (Device Programming Interface) a été détaillée. Elle regroupe les fonctions qu’utilisent les pilotes pour communiquer avec le noyau et pour effectuer des opérations d’entrée-sortie. Lors du traitement d’une tâche par

1.5 Caractérisation des systèmes d’exploitation

31

un pilote, une faute de type paramètre invalide comme celle définie dans BALLISTA est injectée dans les paramètres d’appel à une fonction du noyau.

L’étude expérimentale a porté sur trois pilotes de périphériques (SMC-ultra et Ne2000 comme pilotes de réseau connus pour leur grande taille de code source et SoundBlaster, un pilote de son, comme pilote de taille moyenne) exécutés sur un noyau Linux. Différentes combinaisons de pilotes et de versions du noyau ont été considérées. Pour analyser les résultats expérimentaux, ils proposent un cadre global pour interpréter les résultats. Pour cela, ils caractérisent le noyau selon trois attributs de sûreté de fonctionnement : disponibilité (minimiser les cas du gel de noyau), sécurité-innocuité (minimiser les cas de service incorrect) et le retour des expériences (maximiser la notification des erreurs). Les résultats obtenus montrent que SoundBlaster a le meilleur comportement vis-à-vis du nombre d’erreurs notifiées, même si les résultats concernant la sécurité-innocuité et la disponibilité sont plus médiocres. Les résultats obtenus avec le test du pilote SMC sur deux versions différentes du noyau (2.2 et 2.4 respectivement) montrent le progrès réalisé en termes de notification d’erreurs, même si aucune amélioration n’a été constatée sur les deux autres attributs. Enfin, en comparant les effets de fautes provenant des deux pilotes de réseau SMC et NE2000, ce dernier est un peu meilleur en termes de disponibilité alors que SMC est meilleur en termes de nombre d’erreurs notifiées et de sécurité-innocuité.

Etalonnage des micro-noyaux pour systèmes enfouis

Dans le domaine des systèmes informatiques temps-réel, l’attention se porte non seulement sur les résultats générés par ces systèmes, mais également sur la production de ces résultats dans les contraintes temporelles imposées lors de la spécification de ces systèmes. À

Critical Software [Moreira 2004], des travaux ont été menés pour étalonner la sûreté de

fonctionnement des noyaux temps réel des systèmes spatiaux. L’objectif est de permettre aux développeurs/intégrateurs de ces systèmes d’évaluer et de comparer le déterminisme du temps de réponse des appels système de ces noyaux. Les observations collectées sont combinées dans une seule mesure finale appelée la « prédictibilité du temps de réponse ».