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

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

 Nous allons dans cette section établir les principales causes de la présence de fautes dans les pilotes et des extensions en général. D’après la terminologie présentée dans [Laprie et al. 1995] sur les liens entre faute, erreur et défaillance, l’origine des fautes est l’élément ayant engendré un comportement anormal que l’on souhaite prévenir ou tolérer. Cet élément peut être de nature physique (matériel ou humain) ou logique (logiciel). 

 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. L’utilisation d’un langage spécifique au domaine permet de résoudre ce problème et sera présentée à la fin de ce chapitre. Il convient de rappeler que les pilotes sont souvent écrits par des fabricants de matériels (contrôleurs ou périphériques) plutôt que par les développeurs de systèmes d’exploitation. Ils ne disposent donc pas d’une expérience étendue de la programmation dans le noyau comme ces derniers. La compréhension globale de la gestion des périphériques par un noyau peut s’avérer cruciale lors de l’implémentation d’un pilote. Dans certains cas, les fabricants de matériels développant des pilotes peuvent ne disposer que de peu de connaissances à ce sujet. Par ailleurs, les documentations de la programmation noyau sont destinées à un public averti, souvent difficile d’accès et parfois même confuses. Les connaissances nécessaires à la bonne réalisation d’un pilote sont reparties sur les trois couches informatiques : – la couche applicative, utilisatrice du système; – la couche système hébergeant le noyau; – la couche matérielle impliquée par le pilote que l’on désire concevoir. 

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

 Les développeurs d’un tel logiciel doivent connaître de manière approfondie l’ensemble de ces couches afin d’anticiper les problèmes d’interactions auxquels ils peuvent être confrontés. Or, cette compétence ne se trouve pas fréquemment dans les sociétés fournissant des dispositifs matériels, mais plutôt chez celles qui produisent les systèmes d’exploitation. Elle manque souvent dans les « petites » entreprises souhaitant fournir les pilotes de leurs périphériques. Concernant la couche système, la programmation de pilotes exige souvent de comprendre le fonctionnement de dispositifs asynchrones complexes et également de protocoles de commande évolués. Le nombre de personnes ayant des connaissances approfondies sur les techniques propres aux systèmes d’exploitation n’évolue pas aussi rapidement que la quantité de pilotes à fournir. Il est donc de plus en plus difficile de trouver du personnel qualifié pour ce genre de développement. Toutefois, nous verrons à la fin de ce chapitre les solutions envisagées pour réduire cette difficulté. Une des conséquences découlant de la difficulté à concevoir et développer de tels logiciels est que les pilotes sont fréquemment élaborés en copiant et en éditant le code des pilotes existants, souvent sans maîtrise complète des fonctionnalités réutilisées. Dans des soucis d’économie d’argent et de temps, ce phénomène est très fréquent dans de nombreuses équipes de développement, en particulier chez les fournisseurs de matériel, qui représentent une part importante des concepteurs de pilotes. Facilitant la programmation dans un premier temps, ce genre de pratique conduit à des bogues subtiles, difficilement identifiables comme celui du masquage d’interruption. En effet, la présence des pilotes au cœur du noyau peut amener des problèmes difficilement analysables par le développeur, car les bogues se révèlent généralement en opération et leur correction est jugée trop coûteuse pour être mise en œuvre. L’environnement de la programmation dans le noyau reste très particulier. Il est en général faiblement documenté, que ce soit pour la gestion mémoire, la gestion des accès concurrents ou les règles de préemption. Les outils de développement d’un pilote ne sont pas aussi pratiques que ceux d’une application classique. Les débogueurs sont souvent inefficaces et, de manière plus générale, les IDE (Integrated Development Environment) complets n’ont fait leur apparition que dernièrement. Les contraintes de développement sont plus élevées et les possibilités d’évaluer et de tester les pilotes sont donc réduites. Les bogues ont souvent un fort impact sur le système ce qui rend leur compréhension et leur correction très difficiles. La programmation dans le noyau est faiblement protégée, laissant une grande liberté aux programmeurs dans l’objectif de réaliser des performances. Cette liberté est souvent la source de faiblesses du système. En effet, une part importante de la performance du système provient des logiciels de pilotages. Certains périphériques sont régulièrement sollicités lorsque le système est en opération. Alourdir ces programmes en effectuant des contrôles lors de leur exécution conduit à une réduction sensible de la performance. Pour Linus Torvalds3 , la baisse de performance n’est pas admissible dans le noyau d’un système d’exploitation. Toutefois, avec les progrès matériels modernes, les puissances de calculs sont suffisamment importantes pour rendre une perte de performance négligeable par rapport au gain de sûreté de fonctionnement, en particulier dans des systèmes critiques. Dans ce cadre, la mise en place de systèmes de recouvrement (wrapper) a permis des progrès en termes de sureté de fonctionnement comme sur le module de synchronisation du micronoyau de première génération Chorus dans [Rodriguez et al. 2002]. Les techniques actuelles de conception de pilotes de périphériques comportent de grosses lacunes en terme de qualité de conception logicielle. Les conditions de développement sont souvent très difficiles. Les fautes logicielles sont la principale cause d’erreurs liées aux pilotes. Toutefois, les fautes matérielles représentent une deuxième source d’erreurs. Aujourd’hui faible, sa part risquerait d’augmenter avec la venue d’amélioration de la prévention de fautes logicielles. 

 Les fautes physiques 

Les fautes physiques sont dues à des phénomènes physiques adverses. Elles peuvent être: – Internes: elles proviennent d’une partie défaillante du système. L’activation de cette partie produisant une erreur; – Externes: elles résultent de l’interférence ou des interactions du système avec son environnement physique. Les avancées permanentes de la technologie électronique permettent d’intégrer de plus en plus de transistors sur un seul circuit (VSLI et ULSI), de plus en plus de fonctionnalités sur une seule carte, voire sur un même circuit (SOC). Une analyse de l’évolution des circuits microprocesseurs et mémoires durant les trente dernières années montre un accroissement du nombre de transistors par an de 40% et de 60% pour les mémoires. On peut intégrer aujourd’hui plus d’un milliard de transistors sur un seul circuit. Des mémoires DRAM de plusieurs gigabits existent avec des règles de dessins de 0,1 micromètres. Moins d’un dixième de millimètre sépare chaque composant afin d’accroître la rapidité de traitement de l’information et son transfert. De plus, la loi de Moore énonce que la capacité de transfert des bus double tous les 18 mois. On peut alors constater que les travaux des dernières années ont été portés sur la performance plus que la qualité et la sûreté de fonctionnement. D’après de récents rapports de la société Intel [Edwards & Matassa 2002], il devient de plus en plus difficile aujourd’hui de produire des composants exempts de fautes de conception ou de production. Les perturbations électromagnétiques, les radiations, la température, les vibrations, un matériel défectueux peuvent être à l’origine de fautes physiques. Ces fautes peuvent avoir un impact sur n’importe quel système. Aujourd’hui, les fautes physiques à l’origine d’une défaillance des systèmes d’exploitation les plus répandus représentent une part négligeable des fautes. Ce raisonnement ne serait pas valable dans le cas de domaine très particulier comme, par exemple, le domaine spatial. Nous verrons que certaines techniques existent pour réduire l’impact de ce type de fautes à la fin de ce chapitre. Les fautes logicielles restent donc la principale origine des fautes liées aux pilotes. Pour mieux cerner leurs effets possibles, nous présentons dans le prochain chapitre la composition sémantique puis logicielle d’un pilote de périphériques