À l'avenir, il est clair que l'amélioration de la fiabilité du système d'exploitation dépendra de la fiabilité des pilotes, puisque le noyau n'est plus la principale source d'erreurs. Dans ce chapitre, nous justifions d’abord notre intérêt pour les problèmes liés aux pilotes de périphériques dans l’étude de la sécurité des systèmes d’exploitation.
Source importante d’erreurs
Nous motivons ensuite les techniques de sécurité opérationnelle mises en œuvre pour surmonter les problèmes présentés par les pilotes. La combinaison de ces deux facteurs aggrave considérablement l’influence des pilotes sur la fiabilité opérationnelle des systèmes.
Origines des fautes liées aux pilotes ou aux matériels
Les fautes logicielles
Une part importante des performances du système provient en réalité du logiciel de contrôle. Surcharger ces programmes en effectuant des contrôles lors de leur exécution entraîne une dégradation importante des performances.
Les fautes physiques
Les techniques actuelles de conception de pilotes de périphériques présentent des lacunes majeures en termes de qualité de conception logicielle. Actuellement faible, sa part pourrait augmenter avec l’avènement d’améliorations dans la prévention des erreurs logicielles.
Les pilotes de périphériques dans les systèmes d’exploitationd’exploitation
Rôle
Organisation fonctionnelle
Le processeur passe en mode superviseur et exécute le code du pilote pour l'opération appropriée. Enregistrement et enregistrement du pilote : vous permet d'insérer et de supprimer un code de pilote dans le système d'exploitation.
Commentaires
Par exemple, dans le cas d'un driver de type polling, une application effectue une requête via un appel au noyau (ouverture, lecture, etc.) pour accéder aux données d'un périphérique (par exemple une clé USB). En fin de chapitre, nous présenterons le travail effectué sur différents systèmes pour prévenir et tolérer les pannes provenant du pilote de périphérique.
Les systèmes d’explo itatio n
Architectures et concepts
Certains systèmes d'exploitation utilisent un espace d'adressage partagé pour tous les processus, c'est-à-dire non protégé, comme dans le cas du système d'exploitation Dos. Cependant, dans les deux cas, leur rôle est de fournir une abstraction d'un périphérique pour le système d'exploitation.
Exemples de systèmes d’exploitation
Dans la suite, le terme noyau sera utilisé pour désigner la partie du système d'exploitation qui supervise la machine. Un noyau monolithique de type Unix fournit tout ce dont un système d'exploitation a besoin en termes de services (voir [Bach 1987]) : gestion des processus, gestion de la mémoire, communication interprocessus, accès aux périphériques, système de fichiers, protocoles réseau, etc.
Architecture des pilotes de périphériques
- Linux
- Windows XP
- MacOS X
- Remarques
L'insertion et la suppression d'un pilote de gestion de périphériques se font dynamiquement sous Linux en utilisant le concept de module. L'ajout et la suppression d'un logiciel de gestion de périphériques s'effectuent de manière dynamique dans Windows XP.
Amélioration de la sûreté de fonctionnement
- Amélioration de l’architecture du système
- Amélioration de la phase de conception
- Amélioration par recouvrement du noyau
- Amélioration matérielle
- Amélioration du logiciel
- Remarques
Les auteurs dans [Bershad et al 1995] et [Réveillère & Muller 2001] proposent d'utiliser des langages sécurisés lors de la conception du noyau ou d'un driver pour éviter les erreurs. Lorsque le pilote effectue ces tâches, il appelle les fonctions du noyau.
Conclusion
Enfin, l'efficacité représente le gain par rapport aux besoins réels en matière de sécurité opérationnelle des systèmes d'exploitation. Cela fait des pilotes le problème actuel le plus important en matière de sécurité opérationnelle des systèmes d’exploitation.
Étalon de performances
Unixbench [Smith 1995] est un micro-benchmark dédié à l'évaluation des performances des systèmes Unix. Le but de cet outil est d'identifier et d'évaluer les goulots d'étranglement des performances d'un système d'exploitation.
Évaluation de la sûreté de fonctionnement
Méthode analytique
Les mesures de sécurité opérationnelle sont évaluées en attribuant des valeurs aux paramètres de processus stochastiques du modèle. La modélisation analytique peut être divisée en trois phases étroitement liées : - Le choix des mesures de sécurité opérationnelle à évaluer.
Techniques d’injection de fautes
Il existe de multiples méthodes d'injection de fautes, allant de la simulation de fautes sur un modèle du système (cette observation a par exemple été le point de départ du développement des techniques d'injection de fautes par logiciel).
Étalon de sûreté de fonctionnement pour les systèmes d’exploitationd’exploitation
Dimensions de catégorisation
Mais l’utilisation d’une description détaillée du système peut réduire les chances que la norme soit transférée vers d’autres systèmes. Le cœur du système d’exploitation constitue la base du bon fonctionnement des applications.
Mesures
Sensibiliser aux mécanismes de base du système d’exploitation pris en compte lors de l’enregistrement des mesures de sécurité opérationnelles. Dans la suite de ce paragraphe, nous présentons les différentes mesures qui permettent de caractériser la sécurité opérationnelle d'un système d'exploitation donné.
Dimensions d’expérimentation
Les observations permettent de caractériser le comportement du système cible après l'exécution de l'activité, en présence de la séquence d'erreurs. Certains systèmes dits réflexifs fournissent des mécanismes visant à surveiller et à observer le comportement du système.
Caractérisation des systèmes par injection de fautes
Caractérisation par rapport aux fautes internes et matérielles
Les modèles de propagation des défauts sont construits à la fois pour les défauts matériels et les défauts logiciels. Les erreurs injectées lors de l'exécution du code du noyau provoquent l'arrêt du noyau ou ne produisent aucune sortie visible.
Caractérisation par rapport aux fautes externes
Les résultats obtenus grâce à la technique d'injection MAFALDA dans le noyau Chorus révèlent qu'une bonne partie des erreurs introduites dans le composant fonctionnel de communication sont détectées par les mécanismes de détection d'erreurs du micronoyau. Des expériences d'injection de fautes ont été réalisées après introduction de ces mécanismes d'isolation dans le micronoyau et ont montré l'efficacité de ces mécanismes.
Caractérisation de systèmes vis-à-vis des extensions
Pour caractériser le comportement du système en présence de pilotes de périphériques défectueux, les auteurs présentent une technique d'injection de fautes pour introduire des bogues logiciels. La technique d’injection de fautes utilisée dans cette méthode permet une grande portabilité du standard.
Conclusion
Dans ce chapitre, nous présentons une technique pour évaluer le noyau d'un système d'exploitation par rapport à des pilotes défectueux. C'est pour répondre à cette problématique que nous avons cherché à identifier et décrire cette interface entre les pilotes et le noyau présente dans tous les systèmes d'exploitation actuels [Zaatar & Ouis 2002].
Interface entre les pilotes et le noyau
Introduction à la DPI
Un autre rôle principal d'un pilote de périphérique est de répondre aux demandes des composants matériels. Il est constitué d'un ensemble de symboles (fonctions, structures, variables) disponibles uniquement pour le système d'exploitation : le noyau et les pilotes.
Interface générique aux systèmes d’exploitation
Ce dernier fonctionne directement sur l'appareil ou via les fonctions DPI de plus bas niveau, permettant de gérer des bus ou de la mémoire par exemple. Ils consistent principalement à gérer les minuteries, les interruptions, la mémoire et l'enregistrement des pilotes dans le système.
Le paramétrage des fonctions privilégiées
Critères pour l’évaluation de l’impact des pilotes défaillantsdéfaillants
- Fautes visées
- Portabilité de la méthode
- Des mesures appropriées
- Compléter les étalons existants : DBench
Nous avons souhaité évaluer le comportement du système en termes de sécurité de fonctionnement vis-à-vis de ces erreurs. En revanche, nous considérons que l’utilisateur du standard diffère du développeur du système d’exploitation cible.
Évaluation de la robustesse de la DPI
Technique d’injection de fautes par logiciel
- Tests de robustesse
- Corruption de paramètres
- Représentativité de l’injection de fautes
- Charge de faute
L’utilisation de l’injection d’erreur nécessite au préalable de répondre aux questions suivantes [Arlat et al. Ce travail met en évidence la représentativité des techniques d'injection de fautes logicielles par rapport aux fautes physiques [Czeck 1993] [Kanawati et al.
Charge de travail
Lors de l'évaluation de la robustesse d'un système, chaque paramètre est testé avec différentes valeurs possibles. La charge de travail va donc indirectement déclencher l'utilisation des fonctions d'interface entre les pilotes et le noyau.
Observations
La deuxième exécution de la charge de travail permet, pour chaque expérience, d'évaluer les capacités du système à revenir à un état stable. La chronologie en bas montre le cas où la charge de travail ne se termine pas.
Points de vue et interprétation
- Caractérisation des fautes
- Application à MAFALDA-RT
- Application à notre méthode
- Prise en compte du point de vue
RK1 O1-O3 Un message d'erreur est émis avant que la charge de travail ne soit terminée avec succès. AK1 O1-O3 Un message d'erreur est émis avant que la charge de travail ne soit terminée avec succès.
Conclusion
Par conséquent, nous avons volontairement exclu cette catégorie d’observations de l’analyse des résultats, compte tenu des perspectives de sécurité opérationnelle. La méthode présentée dans le chapitre précédent permet d'évaluer la stabilité de l'interface d'un noyau de système d'exploitation vis-à-vis d'un driver défaillant.
L’interface pilote noyau de Linux
- Les symboles de Linux
- Les types dans Linux
- Intervalles de validité des classes de paramètres
- Les types dans Windows
Les autres classes de types sont courantes et se trouvent généralement dans le code des systèmes d'exploitation modernes. La particularité des classes de types présentées dans le paragraphe précédent réside dans leur intervalle de validité.
Plate-forme expérimentale
- Description générale
- Spécifications du profil d’exécution
- Charge de fautes
- Charge de travail
- Injection de fautes
- Observations et mesures
- Application à Windows XP
Il s'agit d'un résultat reproductible de l'exécution de la charge de travail sur la machine évaluée dans un environnement sans erreur. La machine enregistre le début et la fin de chaque exécution de charge de travail.
Déroulement d’une campagne d’expériences
Détermination des symboles ciblés
Nous pouvons alors comparer la robustesse de fonctions de service d’interface similaires entre deux versions du noyau. Lorsque nous examinons les signatures de fonctions, les fonctions sont en fait classées dans un service du noyau.
Conduite de la campagne d’injection de fautes
Le temporisateur (n) est initialisé pour signaler un redémarrage correct de la machine pour l'expérience en cours. Une deuxième interruption est déclenchée pour permettre la lecture du code retour, puis l'exécution de la charge de travail reprend (tWContinue).
Stockage des données
En effet, des redémarrages brusques et répétés peuvent provoquer des erreurs dans le système de fichiers et provoquer un état instable permanent de la machine. En pratique, sa valeur vaut quatre fois le temps d'exécution de la charge de travail utilisée pour conserver une « marge de sécurité » importante.
Résultats et Analyses
Analyse préliminaire
- Les limites de l’observation
- Premières analyses
Un rapide coup d’œil à ces résultats montre un taux d’interruption de charge de travail très faible pour toutes les expériences réalisées. Généralement, il s'agit du seul événement collecté au cours de l'expérience, à moins qu'un blocage du cœur ne soit observé après la fin de la charge de travail (de tels cas sont rares).
Points de vue et interprétation
- Notifications d’événements
- Sûreté de la charge de travail
- Disponibilité du noyau
- Synthèse
Cette baisse correspond au signalement des erreurs qui précèdent la terminaison du noyau ou des événements inappropriés de terminaison de charge de travail. L'analyse du point de vue de la sécurité des charges de travail révèle un comportement similaire à celui effectué du point de vue de la notification des événements du noyau : à 53 %.
Analyse détaillée
- Répartition des défaillances par fonctions
- Critères de sûreté de fonctionnement et de performance
- Choix des critères de sûreté de fonctionnement
- Amélioration de la sûreté de fonctionnement : le symbole iget4
La fonction eth_copy_and_sum présente dans le DPI de Linux version 2.2.20 provoque de nombreux crashs du noyau. Les résultats des expérimentations réalisées sur la version 2.4 de la fonction iget4 montrent un meilleur comportement du point de vue de la disponibilité du noyau.
Conclusion
Experimental Evaluation of a COTS system for space applications”, v Proceedings International Conference on Dependable Systems and Networks (DSN-2002), (Whasington DC, USA), str. Robustness Testing and Hardening of CORBA ORB Implementations”, v Proceedings International Conference on Zanesljivi sistemi in omrežja (DSN-2001), (Göteborg, Švedska), str. 141-150, IEEE CS Press, 2001.
