Caractérisation de systèmes d’exploitation en présence de pilotes défaillants

Les systèmes informatiques sont de plus en plus présents dans notre quotidien et les besoins en sûreté de fonctionnement ne se limitent plus aux domaines critiques classiques comme celui du ferroviaire, de l’avionique, du spatial ou du nucléaire. Les ordinateurs de bords embarqués dans les voitures, les serveurs sur Internet à rendement élevé (e-commerce, systèmes bancaires et transactionnels) constituent désormais des systèmes critiques par leurs impacts humain et financier. Une défaillance dans un de ces systèmes peut avoir des conséquences catastrophiques sur son environnement. En effet, imaginez les conséquences si le système ABS de votre voiture s’enclenche spontanément ou si votre banque en ligne est indisponible pendant trois jours. Longtemps, les systèmes critiques ont traditionnellement utilisé des composants matériels et logiciels spécifiques, élaborés par des concepteurs avertis des besoins de sûreté de fonctionnement du système global. Aujourd’hui, cette pratique est devenue souvent irréalisable à cause de son coût en temps et en main-d’œuvre. De plus, même dans ces conditions, l’élimination complète des fautes logicielles s’avère très difficile voire impossible compte tenu des contraintes de développement et de test. En effet, il est établi que la plupart des composants logiciels contiennent des fautes résiduelles lors de leur distribution.

Afin principalement de réduire les coûts de développement, la tendance est à l’utilisation de composants logiciels disponibles immédiatement ou « sur étagère ». Ils peuvent être commerciaux, souvent cités sous l’acronyme « COTS». En raison de l’opacité qui est souvent attachée à l’offre commerciale et les coûts significatifs pour obtenir le code source, l’option « source libre » se présente progressivement comme une alternative prometteuse. Les résultats de plusieurs études ont montré que les solutions « source libre » n’exhibaient pas nécessairement davantage de comportements critiques et ont même mis en évidence, dans certains cas, de meilleurs résultats que des solutions commerciales équivalentes.

LA PROBLÉMATIQUE DES PILOTES

Aujourd’hui, les logiciels de gestion de périphérique posent un problème majeur en termes de sûreté de fonctionnement. De nombreuses études réalisées sur différentes plates-formes montrent que les pilotes sont fréquemment à l’origine des dysfonctionnements des systèmes d’exploitation. Ce phénomène n’épargne aucun des systèmes d’exploitation répandus comme ceux des familles Windows et GNU/Linux. Les raisons du taux élevé des défaillances dans les pilotes sont multiples et sont abordées dans ce chapitre. La conception et la réalisation d’un pilote s’effectuent dans des conditions difficiles, et la réalisation d’un pilote de périphériques performant et sûr de fonctionnement nécessite des connaissances approfondies de la part du concepteur et du développeur. L’environnement particulièrement complexe d’un logiciel de gestion de périphérique amplifie ces difficultés.

Le succès des nouveaux périphériques informatiques aggrave l’impact des pilotes. En effet, pour répondre à l’augmentation croissante et rapide de matériels gérés par le système (caméras, cartes diverses), les systèmes d’exploitation commerciaux sont étendus en chargeant du code peu sûr directement lié avec le noyau. Nous présentons dans ce chapitre les tentatives pour diminuer les risques dans le noyau. Elles exigent souvent de changer la manière d’écrire le code ou d’effectuer des modifications dans la structure des systèmes d’exploitation. De telles approches sont donc parfois difficiles à mettre en œuvre dans le cas des modules de gestion de périphérique, qui sont les extensions les plus communes des systèmes d’exploitation et représentent un investissement énorme en temps d’élaboration. Par conséquent, ces approches n’intègrent pas, à ce jour, les systèmes d’exploitation traditionnels. Aujourd’hui, le besoin des utilisateurs de systèmes n’est pas simplement l’analyse ou la détection de la défaillance, mais également le rétablissement rapide du système pour pouvoir bénéficier de ses services. Par conséquent, le système d’exploitation ne doit pas simplement isoler les modules de gestion de périphérique défectueux, mais leur permettre également de reprendre rapidement le service, après un redémarrage ou après une procédure de recouvrement du système en exploitation (sans redémarrage de la machine). À l’avenir, il est clair que l’amélioration de la sûreté de fonctionnement du système d’exploitation dépendra de la sûreté de fonctionnement des pilotes car le noyau n’est plus la source principale des bogues. Dès lors que le logiciel mûrit et que les dispositifs d’intégration se rétrécissent, les défaillances de matériel (et les fautes physiques) deviendront un plus grand problème. En conséquence, les logiciels d’exploitation doivent permettre de :

– Tolérer et récupérer des pilotes défectueux,
– Tolérer et récupérer du matériel défectueux.

SOURCE IMPORTANTE D’ERREURS

Nous allons voir dans ce paragraphe les différentes recherches effectuées durant les dix dernières années sur les origines des dysfonctionnements des systèmes d’exploitation. En 1999, la principale cause d’instabilité du système d’exploitation Windows NT [Russinovich 99] était attribuable aux modules de gestion de périphériques. Lorsque le système fut largement adopté à travers le monde, le nombre associé d’applications augmenta considérablement. En outre, la plupart des périphériques fonctionnant sur une architecture x86 étaient disponibles pour Windows NT. Son éditeur, la firme Microsoft, estime qu’environ 12000 applications et 24000 périphériques sont associés à NT. Bien que la mise à disposition d’un grand nombre d’applications et de périphériques fasse de NT un système attrayant, facile à employer et à mettre en œuvre, cette richesse augmente aussi ses faiblesses. Les modules de gestion de périphérique mal écrits donnent aux utilisateurs l’impression que NT est un système instable. Même si les pilotes certifiés HLC (certification établie par Microsoft) sont légèrement moins sujets à défaillances, ils restent une importante source d’erreurs. Microsoft n’avait fourni jusque-là que des outils limités aux administrateurs. Le fardeau du développement correct des applications et des pilotes revenait à leurs concepteurs, pas toujours aptes à relever le défi en termes de sûreté de fonctionnement. Mais le problème ne se réduit pas aux systèmes d’exploitation de la firme de Seattle. En 2001, une étude conduite à l’université de Stamford a révélé que les pilotes Linux (pour une architecture x86) représentent soixante-dix pour cent des lignes de code du noyau [Chou et al. 2001]. Durant les dix dernières années, l’augmentation par dix de la taille du noyau est presque exclusivement due à l’augmentation du nombre de pilotes. Dans le même temps, le reste du noyau conserve une taille stable. Ce n’est donc pas une surprise de voir une grande partie des erreurs affectant le code du système être localisée au niveau des pilotes. Représentant la plus forte part en termes de lignes de code, ils risquent de contenir plus d’erreurs de programmation que le reste du système. Mais les résultats obtenus par une analyse statique dans [Chou et al. 2001] avec un ensemble de vérifieurs révèlent un autre constat : La fréquence des bogues par lignes de code dans les pilotes est trois à sept fois supérieure à celle du reste du système d’exploitation. Plus récement, la société Coverity a annoncé dans [LWN Coverity 2004] que son produit SWAT (un analyseur statique de code très sophistiqué mais sous licence propriétaire) avait décelé 985 bogues sur un total de 5.7 millions de lignes de code dans le noyau Linux 2.6.9. La majorité des bogues se trouve dans les modules des pilotes et seulement 1% dans le noyau. Le ratio est donc d’environ 0.17 bogues par millier de lignes ce qui, selon l’université Carnegie Mellon, est beaucoup moins que les logiciels classiques.

En intégrant des concepts de sûreté de fonctionnement lors des perfectionnements de Windows 2000, Microsoft a donné aux développeurs des outils pour corriger les problèmes dans les applications et les pilotes pendant leur conception, lors de la phase de test. Cependant une analyse en opération des défaillances de Windows 2000 a montré que les modules de gestion de périphériques représentent encore 27% des incidents, comparé à 2% pour le noyau lui-même [Murphy & Levidow 2000]. Ce problème est aggravé par la popularité de nouveaux périphériques, comme les appareils numériques pour le grand public (caméras par exemple), qui augmentent le nombre de pilotes à fournir et donc le nombre de défaillances qui leur sont associées. Les efforts fournis dans Windows XP se composent, entre autres, d’un environnement dédié au développement de pilotes (Device Developement Kit) ayant pour objectif de consolider la programmation des pilotes par l’utilisation d’une interface accessible et claire. Malgré cela, en 2003, les pilotes causent encore 85% des échecs rapportés dans Windows XP selon un article interne rédigé par Rob Short .

La fréquence des erreurs de programmation reste largement supérieure dans les modules de gestion de périphérique que dans le reste du noyau. Le phénomène est aggravé par le fait que cette fréquence d’erreurs élevée concerne la plus grosse partie du système en opération. Alors que le noyau du système atteint des niveaux élevés de fiabilité grâce à sa longévité et aux essais répétés, le système étendu (comprenant les pilotes) reste encore la source de nombreuses défaillances. Nous allons voir dans le paragraphe suivant leurs origines.

Origines des fautes liées aux pilotes ou aux matériels

Les fautes logicielles

Les fautes de nature logicielle résultent généralement de compromis effectués durant le développement du programme dans l’objectif de conserver le système à un niveau de performance acceptable, afin de faciliter sa conception, ou encore pour des raisons économiques. Elles peuvent aussi intervenir lors d’interactions non prises en compte pendant la phase de conception et qui se révèlent seulement lors de la mise en opération. La complexité intrinsèque de la conception d’un pilote de périphérique est importante : le pilote doit allier performance, sûreté de fonctionnement et compatibilité avec les différentes versions de matériels et de systèmes.

Les spécifications informelles lors de la conception peuvent être aussi une importante source de difficulté. Les travaux rapportés dans [Gaudel 1991] expliquent comment les spécifications sont une source potentielle de malentendu lors de la conception d’un logiciel. En effet, le langage humain est souvent soumis à l’interprétation, d’une part lors de la phase de conception du cahier des charges et d’autre part lors de la phase d’implémentation. La formalisation des besoins du «client » (l’entité souhaitant le produit) peut conduire le concepteur à l’interprétation. D’une manière similaire, l’intégrateur ou le développeur doit interpréter le cahier des charges pour réaliser le logiciel demandé. Ces interprétations sont fréquemment la cause d’erreurs lors de la conception d’un logiciel. La terminologie propre au domaine des pilotes de périphériques (programmation noyau) et le mélange des niveaux d’abstraction accentuent les limites du langage humain. Les risques d’interprétations biaisées augmentent et l’utilisation de moyens traditionnels de conception de logiciels montre ses limites.

Table des matières

INTRODUCTION GÉNÉRALE
CHAPITRE 1 LA PROBLÉMATIQUE DES PILOTES
1.1 SOURCE IMPORTANTE D’ERREURS
1.2 ORIGINES DES FAUTES LIÉES AUX PILOTES OU AUX MATÉRIELS
1.2.1 Les fautes logicielles
1.2.2 Les fautes physiques
1.3 LES PILOTES DE PÉRIPHÉRIQUES DANS LES SYSTÈMES D’EXPLOITATION
1.3.1 Rôle
1.3.2 Organisation fonctionnelle
1.3.3 Commentaires
1.4 LES SYSTÈMES D’EXPLOITATION
1.4.1 Architectures et concepts
1.4.2 Exemples de systèmes d’exploitation
1.5 ARCHITECTURE DES PILOTES DE PÉRIPHÉRIQUES
1.5.1 Linux
1.5.2 Windows XP
1.5.3 MacOS X
1.5.4 Remarques
1.6 AMÉLIORATION DE LA SÛRETÉ DE FONCTIONNEMENT
1.6.1 Amélioration de l’architecture du système
1.6.2 Amélioration de la phase de conception
1.6.3 Amélioration par recouvrement du noyau
1.6.4 Amélioration matérielle
1.6.5 Amélioration du logiciel
1.6.6 Remarques
1.7 CONCLUSION
CHAPITRE 2 ÉTALONNAGE DE SÛRETÉ DE FONCTIONNEMENT
2.1 ÉTALON DE PERFORMANCES
2.2 ÉVALUATION DE LA SÛRETÉ DE FONCTIONNEMENT
2.2.1 Méthode analytique
2.2.2 Techniques d’injection de fautes
2.3 ÉTALON DE SÛRETÉ DE FONCTIONNEMENT POUR LES SYSTÈMES D’EXPLOITATION
2.3.1 Dimensions de catégorisation
2.3.2 Mesures
2.3.3 Dimensions d’expérimentation
2.4 CARACTÉRISATION DES SYSTÈMES PAR INJECTION DE FAUTES
2.4.1 Caractérisation par rapport aux fautes internes et matérielles
2.4.2 Caractérisation par rapport aux fautes externes
2.4.3 Caractérisation de systèmes vis-à-vis des extensions
2.5 CONCLUSION
CHAPITRE 3 MÉTHODOLOGIE
3.1 INTERFACE ENTRE LES PILOTES ET LE NOYAU
3.1.1 Introduction à la DPI
3.1.2 Interface générique aux systèmes d’exploitation
3.1.3 Le paramétrage des fonctions privilégiées
3.2 CRITÈRES POUR L’ÉVALUATION DE L’IMPACT DES PILOTES DÉFAILLANTS
3.2.1 Fautes visées
3.2.2 Portabilité de la méthode
3.2.3 Des mesures appropriées
3.2.4 Compléter les étalons existants : DBench
3.3 ÉVALUATION DE LA ROBUSTESSE DE LA DPI
3.3.1 Technique d’injection de fautes par logiciel
3.3.2 Charge de travail
3.3.3 Observations
3.4 POINTS DE VUE ET INTERPRÉTATION
3.4.1 Caractérisation des fautes
3.4.2 Application à MAFALDA-RT
3.4.3 Application à notre méthode
3.4.4 Prise en compte du point de vue
3.5 CONCLUSION
CHAPITRE 4 MISE EN ŒUVRE EXPÉRIMENTALE ET RÉSULTATS
CONCLUSION

Lire le rapport complet