4.7 Mécanismes d’encapsulation pour un intergiciel
4.7.3 Contrôler l’interaction entre l’intergiciel et les objets distants
Un dernier candidat pour la mise en place de mécanismes d’encapsulation pour un intergiciel concerne l’interaction avec les objets distants, via des requêtes IIOP. Nous avons vu au §3.2que certains courtiersCORBAsont très sensibles à la corruption de messages IIOP. Deux techniques d’encapsulation peuvent être utilisées pour se prému- nir contre l’impact de fautes arrivant via cette interaction avec des objets distants :
• l’addition d’un CRC au niveau applicatif à tous les messages IIOP. Ce CRC serait calculé par le courtier à l’origine de la requête, et si le courtier côté serveur détecte une anomalie, il peut lever une exception COMM_FAILURE pour indiquer qu’une erreur de communication est survenue.
Une technique prometteuse pour implémenter ces CRCs de manière transparente à l’application serait d’utiliser les Portable Interceptors, qui ont été intégrés dans la version 2.4 de la normeCORBA. Le CRC serait ajouté au service context par un intercepteur côté client, et vérifié par un intercepteur côté serveur. Malheureuse- ment, cette approche n’est pas opérante puisque les intercepteurs côté serveur ne
sont appelés qu’après déballage des paramètres de la requête. Étant donné que la majorité des défaillances que nous avons observées concernaient justement la phase de déballage de la requête, cette technique ne permettrait pas une protection contre les défauts de robustesse que nous avons constatés.
Cette approche ne fournit évidemment pas de protection contre des fautes malveillantes, puisqu’une entité malveillante dans le système peut émettre des requêtes corrompues, mais avec un CRC correct, qui ne seraient pas détectées par les wrappers.
• l’utilisation d’une couche d’encapsulation au niveau de la couche de transport, en utilisant IIOP sur TLS. Cette approche protège contre les fautes accidentelles, puisque le protocole TLS intègre des mécanismes de détection d’erreur supplé- mentaires à ceux de TCP. Elle protégerait également contre les malveillances, puisque les messages dont la signature n’est pas valide pourraient être rejetés par les serveurs.
Cette approche est loin d’être parfaite. Le coût en performance de cette technique d’encapsulation n’est pas négligeable. D’autre part, nous avons vu au §3.5.3
(page94) que l’utilisation de la bibliothèque OpenSSL (qui implémente le chif- frement et l’authentification TLS) n’est elle-même pas exempte de faute. On le voit, la nature répartie du rôle joué par un intergiciel de communication, et sa manière (presque incestueuse) de s’immiscer dans le code applicatif, font qu’il est difficile d’utiliser des méthodes d’encapsulation pour contrôler toutes les interactions du système avec cette « glue » logicielle.
L’intégration étroite d’un intergicielCORBAavec le code applicatif qu’il sou- tient, rend difficile l’encapsulation du courtier dans une zone de confine- ment qui lui serait dédiée.
4.8 Récapitulatif
Comme nous l’avons vu au chapitre 2, un intergiciel de communication fournit un service qui dépend de la communication entre plusieurs nœuds de calcul, ce qui l’expose à une plus grande variété de classes de fautes que les couches exécutives plus basses. Il est donc nécessaire de mettre en œuvre un ensemble de techniques d’injection de fautes, pour fournir une caractérisation expérimentale qui soit complète. Nous avons analysé les résultats de campagnes expérimentales qui ont appliqué ces techniques sur des services et des courtiersCORBA, en cherchant à identifier la cause des comportements non robustes observés. Cette analyse indique que la gestion de la mémoire est un aspect déterminant pour la robustesse d’un courtier : une proportion importante des défaillances observées sont dues à l’absence de vérification du bon déroulement d’une demande d’allocation mémoire. Ces résultats illustrent également
l’importance du support exécutif sur la robustesse. Un exécutif langage comme la machine virtuelle Java offre plusieurs avantages.
Ces différentes techniques ont des coûts de développement et d’utilisation différents, et une capacité variable à mettre en défaut la robustesse des intergiciels candidats. Lorsqu’il n’est pas possible d’appliquer l’ensemble des techniques que nous avons pro- posées, les techniques d’injection de messages IIOP corrompus, associées à l’utilisation de saboteurs au niveau du système d’exploitation, nous paraît comme étant un bon choix de techniques, qui devrait donner une bonne idée des modes de défaillance des différents candidats.
Chapitre 5
Conclusions et perspectives
N
Ous dressons dans ce chapitre les conclusions de notre étude, à la fois pour les intégrateurs d’intergiciel dans les systèmes répartis semi-critiques, et pour les développeurs d’intergiciel. Nous analysons également les perspectives qui pourraient prolonger cette thèse.Nous avons vu que les composants intergiciel sont exposés à un ensemble de fautes plus large que d’autres couches exécutives, telles que les systèmes d’exploitation et les exécutifs de langage de programmation. De plus, les fonctionnalités fournies par un intergiciel de communication sont de par leur nature plus difficiles à caractériser, puisqu’elles sont implémentées et utilisées de manière distribuée ; comme d’autre part l’intergiciel doit principalement assurer des propriétés de transparence, ces fonction- nalités sont fournies implicitement plutôt que suite à un appel explicite. Pour toutes ces raisons, une gamme de techniques d’injection de faute est nécessaire afin de caractériser de manière complète le comportement de ces composants logiciels en présence de faute.
Dans ce manuscrit, nous avons analysé les systèmes à base d’intergiciel de commu- nication, afin de proposer un modèle de fautes adapté à leurs caractéristiques et de déterminer une classification de leurs modes de défaillance. À partir de cette étude, nous avons motivé les lignes directrices d’une méthode expérimentale pour évaluer la robustesse et caractériser le comportement en présence de fautes de ces intergiciels de communication. Cette méthode repose sur la définition d’un ensemble de techniques d’injection de fautes, certaines classiques, et d’autres plus originales et plus spécifiques à la cible. Ces techniques ciblent les fautes internes au niveau du matériel et du logiciel, ainsi que les fautes qui se propagent depuis les nœuds distants.
Nous avons focalisé nos travaux sur la référence en matière d’intergiciels de com- munication, la plate-forme CORBA. Afin de valider notre approche, nous avons mené des campagnes d’injection de fautes ciblant un certain nombre d’implantations de cette norme. Nous avons évalué le comportement des services de désignation et de
diffusion d’événements de différents fournisseurs face à la réception de messages corrompus. Nous avons examiné l’impact de comportements inattendus du système d’exploitation sur différents candidats intergiciels. Nous avons évalué la robustesse des outils de développement d’un fournisseur d’intergiciel en appliquant des techniques de mutation de code à des interfaces IDL.
Notre travail d’analyse de la sûreté de fonctionnement permet de caractériser les modes de défaillance de l’intergiciel, d’identifier les canaux de propagation d’erreur par l’intergiciel, et accessoirement d’analyser ses vulnérabilités en termes de sécurité informatique. En recoupant les résultats de nos différentes campagnes d’injection de fautes, nous avons proposé une métrique permettant d’obtenir une mesure quantita- tive de la robustesse d’un candidat intergiciel.
Finalement, nous avons démontré comment les travaux de caractérisation peuvent servir à l’identification de fautes de conception et d’implantation dans les composants intergiciels, et nous avons illustré des techniques d’empaquetage permettant de ren- forcer la robustesse de courtiers du commerce, afin de les rendre mieux adaptés à des applications de type semi-critique.
5.1 Remarques pour les intégrateurs d’intergiciel
Les intergiciels de communication constituent une technologie privilégiée pour l’intégration de systèmes hétérogènes dans un contexte réparti. Ils permettent la communication entre des systèmes implémentés dans des langages de programmation différents, et s’exécutant sur des plates-formes logicielles et matérielles hétérogènes. Toutefois, l’utilisation de cette « glue » logicielle n’est pas sans conséquences sur la robustesse des systèmes. En effet : le code de l’intergiciel peut contenir des fautes du logiciel ; l’intergiciel peut servir de canal de propagation d’erreur dans le système ; par son intégration étroite avec le niveau applicatif, il peut entraîner la défaillance d’objets ou de services.
La propriété de transparence qui est fournie par un intergiciel de communication simplifie la mise en œuvre d’applications réparties, puisqu’elle permet de s’abstraire d’un certain nombre de problèmes liés à la répartition. Toutefois, cette transparence de la répartition des calculs n’est qu’une illusion, et toute illusion a un prix : ici d’abandonner la maîtrise des interactions entre les objets du niveau applicatif et le code de l’intergiciel. L’intergiciel ne se laisse pas facilement apprivoiser ; il est difficile de le confiner dans une boîte dont on maîtrise toutes les entrées et toutes les sorties.
La transparence est l’ennemi du contrôle. Un intergiciel transporte les re- quêtes entre objets de manière transparente, mais peut également propager les erreurs de manière sournoise.
Pour une utilisation dans un système critique, il nous semble qu’une architecture d’intergiciel offrant moins de transparence serait préférable au niveau d’intégration élevé qui est fourni par CORBA. Le transfert de contrôle vers l’intergiciel devrait être explicite, et il devrait être possible de contrôler l’interaction entre le niveau applicatif et le niveau de l’intergiciel1.