conséquences catastrophiques sur l’état du système. Les résultats qu’il est possible d’obtenir à partir de nos travaux permettent de mieux appréhender cet impact.
3.2 Critères pour l’évaluation de l’impact des pilotes
complète. Ce genre de pratique conduit à des bogues subtiles, difficilement identifiables, car la présence des pilotes au cœur du noyau peut conduire à des problèmes souvent difficilement analysables par le développeur de pilote.
Les techniques actuelles de conception de pilotes de périphériques comportent de grosses lacunes en terme de qualité de logiciel. Les conditions de développement sont souvent très difficiles et il en résulte que les fautes logicielles résiduelles sont la principale cause d’erreurs liées aux extensions. Toutefois, les fautes matérielles représentent une deuxième source d’erreurs. Aujourd’hui faible, leur part risquerait d’augmenter avec la venue d’amélioration de la prévention de fautes logicielles. Ces types de fautes, externes au noyau, sont aujourd’hui responsables d’un grand nombre de défaillances des systèmes d’exploitation. Nous avons souhaité évaluer le comportement du système en terme de sûreté de fonctionnement vis-à-vis de ces fautes.
3.2.2 Portabilité de la méthode
Les systèmes principalement ciblés par nos travaux sont les systèmes d’exploitation à usage général comme Windows ou GNU/Linux. Le principal objectif de la caractérisation est la comparaison des résultats obtenus lors de l’évaluation du comportement de plusieurs systèmes d’exploitation distincts, dans notre cas vis-à-vis de pilotes défaillants. Nous allons discuter dans ce paragraphe des contraintes que nous nous sommes fixées pour établir une approche standard des systèmes d’exploitation modernes. En effet, durant le chapitre 2, nous avons vu que la reconnaissance du domaine est essentielle pour la crédibilité de l’approche et l’obtention de critères reconnus avec des mesures comparables.
La possibilité de disposer d’une description détaillée du système cible permettrait d’effectuer des analyses plus précises mais en contrepartie elle en réduirait le portage. Il convient ainsi de conserver une portabilité importante de la méthode d’évaluation. Comme présenté dans le premier chapitre dans les dimensions de catégorisation, nous avons donc opté pour une approche globale du système en prenant le noyau comme cœur du système d’exploitation : il assure le lien entre les applications et le matériel en se basant, entre autres, sur les logiciels de pilotage des périphériques. C’est la sûreté de fonctionnement de ce noyau minimal que nous cherchons à évaluer au cours de nos travaux. Toutefois, le noyau pourra être l’objet d’une analyse plus précise, par exemple en analysant chacune de ses parties, pour obtenir des résultats plus précis sur l’évolution d’un noyau.
D’autre part, nous considérons que l’utilisateur de l’étalon est différent du développeur du système d’exploitation cible. C’est pourquoi nous supposons :
- une connaissance limitée de la structure interne du système ; - un accès limité aux codes des pilotes et du noyau.
Cette vision du système est proche de celle appelée couramment « boîte noire ». Nous considérons que nous ignorons les mécanismes internes au composant ciblé, et qu’en particulier nous ne disposons pas de son code source. Ce point de vue assure une meilleure portabilité de la méthode à différents systèmes. En effet, l’architecture interne du noyau n’étant pas prise en compte, les techniques d’évaluation peuvent être plus aisément réutilisées, sur des systèmes différents. Au niveau de la connaissance des codes source des systèmes cibles, cette
approche permet de s’intéresser de manière indifférente à des systèmes à code source ouvert ou non.
Nous avons étendu cette vision opaque du code source au niveau des pilotes. En effet, la prise en compte du contenu des pilotes de périphériques dans une méthode d’étalonnage des systèmes pourrait faire émerger des difficultés lors du portage à des systèmes d’exploitation distincts. En effet, des systèmes d’exploitation comme Linux et Windows utilisent des pilotes de périphériques aux codes sources radicalement différents. L’approche « boîte noire » d’un composant permet de s’affranchir de prise en compte de la structure interne de celui-ci. Ses interfaces avec son environnement restent les seuls éléments connus. C’est le cas des interfaces d’un noyau de système d’exploitation, qui sont connues du public et constituent donc une localisation particulièrement intéressante pour l’étude de l’impact des pilotes de périphériques sur le reste du système.
3.2.3 Des mesures appropriées
Nous avons observé dans le paragraphe précédent que les interfaces représentaient des localisations privilégiées pour la caractérisation d’un système d’exploitation. En effet, elles font partie du système et composent la partie visible pour son environnement (les applications et les pilotes). Comme nous l’avons vu au chapitre 2, la caractérisation d’un composant vis-à- vis de fautes externes permet l’évaluation des mesures de robustesse. Nous verrons, dans ce paragraphe, la possibilité d’élargir les mesures obtenues au-delà des mesures de robustesse.
Dans notre approche, l’environnement opérationnel potentiellement défaillant concerne les logiciels de pilotage des périphériques du système d’exploitation, les effets des applications et du matériel étant évalués dans d’autres travaux. Cependant, une même erreur peut avoir des origines distinctes, les fautes dans les pilotes peuvent alors être représentatives de fautes provenant du matériel. Nous reviendrons sur la représentativité des fautes à la fin de ce chapitre.
Nous avons vu que la caractérisation du système à fonctionner correctement en présence d’entrées invalides ou de conditions environnementales stressantes forme une mesure de robustesse particulièrement intéressante. Plus concrètement, elle s’établit par l’observation de deux classes d’événements :
- Les modes de défaillance du système lorsque l’erreur est propagée au système cible. Ils correspondent ici à l’état des applications s’exécutant sur le système.
- Les mécanismes de détection ou de tolérance quand l’erreur est confinée au niveau de l’interface ou à l’intérieur du système. Ils sont généralement composés des mécanismes de notification d’événements internes et des codes retour des fonctions composant l’interface visée par les entrées erronées.
Cependant, une évaluation au niveau d’une interface permet également la mesure efficace d’une donnée essentielle aujourd’hui : le temps. Les mesures fournies par les étalons de performance permettent la comparaison de la performance de certains mécanismes et services fournis par les systèmes d’exploitation. Aucun de ces étalons ne fournit de mesures de sûreté de fonctionnement. Cependant, il est possible de les réutiliser dans un contexte d’étalonnage de
sûreté de fonctionnement pour pouvoir mesurer la « dégradation » de la performance en présence de fautes.
En effet, le temps de réponse à une requête formulée via les fonctions du système est une information très importante pour l’évaluation du service d’un système d’exploitation vis-à-vis de défaillances applicatives (voir [Kalakech et al. 2004] et [Koopman et al. 1997]). De manière similaire, l’analyse de la dégradation temporelle des services du système en présence d’extensions défaillantes est une donnée intéressante pour la comparaison des systèmes. La meilleure méthode pour évaluer l’impact des pilotes de périphériques sur les services du noyau est l’intégration d’une charge applicative témoin s’exécutant pendant l’injection de fautes.
Nous verrons la composition de cette charge dans la partie implémentation décrite dans le prochain chapitre.
3.2.4 Compléter les étalons existants : DBench
Nous avons vu durant le deuxième chapitre que la caractérisation des systèmes d’exploitation peut être effectuée en prenant en compte trois origines distinctes de perturbation : les fautes logicielles provenant des applications, les fautes provenant matériel et, dans le cas nous concernant, les fautes logicielles résiduelles dans les pilotes de périphériques.
Un concepteur de système à base de COTS souhaite obtenir des informations aussi objectives que possible sur la sûreté de fonctionnement du composant qu’il souhaite intégrer, c’est-à-dire le noyau, et non celle qui concerne un ensemble incluant ce composant, comme le noyau étendu. En effet, le système à base de COTS qui intégrera le composant évalué et le composant lui-même ne disposent probablement pas des mêmes architectures et périphériques matériels sous jacents. Les mesures de sûreté de fonctionnement doivent donc considérer principalement le noyau minimaliste du système d’exploitation et cibler le comportement de ce COTS vis-à- vis de son environnement potentiel. Les travaux effectués dans [Kalakech et al. 2004]
permettent d’évaluer l’impact sur le comportement du système des fautes provenant des applications. Nous complétons ces travaux en explorant l’environnement potentiel des pilotes et en élaborant une méthodologie permettant de distinguer le noyau de ses extensions. Ces résultats intéressent les développeurs de noyaux car, si la distinction des erreurs provenant des pilotes et du noyau est établie, la responsabilité du noyau pourrait être écartée dans de nombreux cas, libérant les gros groupes industriels comme Microsoft et Apple d’une part de la responsabilité des défaillances des systèmes d’exploitation en opération.
Ce phénomène est accentué pour les raisons déjà évoquées au début du premier chapitre. Les pilotes sont une source d’erreurs très importante et leur prise en compte est aujourd’hui essentielle. À l’inverse, les noyaux des systèmes d’exploitation bénéficient d’une expérience de retour importante. Le noyau Linux a disposé de plus de 15 ans de fonctionnement en opération pour améliorer et corriger les nombreux bogues résiduels que comportait sa version initiale. Il en est de même pour Microsoft, la firme américaine distribue son logiciel Windows depuis maintenant une quinzaine d’années. Les programmeurs de noyaux de systèmes d’exploitation sont donc des personnes souvent très qualifiées et disposant d’une grande expérience. Les fautes provenant du noyau et de ses extensions dans le cadre d’un étalon de sûreté de fonctionnement d’un système d’exploitation doivent donc être distinguées. C’est dans cet objectif que nos travaux s’intègrent dans le cadre du projet DBench.