Les hyperviseurs résolvent tous vos problèmes de partitionnement de logiciels. Ou le font-ils ?

Il est bien connu que l’utilisation du partitionnement logiciel, c’est-à-dire l’exécution d’applications dans des environnements séparés, aide à répondre aux exigences de sûreté et de sécurité. Très souvent, les hyperviseurs sont considérés comme la meilleure et/ou la seule solution pour cela, cependant, c’est loin d’être vrai. Les hyperviseurs eux-mêmes peuvent introduire des risques et des vulnérabilités supplémentaires. Cet article propose donc une approche différente : le noyau de séparation.

Les hyperviseurs intégrés permettent à plusieurs systèmes d’exploitation de s’exécuter sur la même plate-forme matérielle, maximisant les performances matérielles tout en garantissant l’indépendance. Ces solutions de virtualisation embarquées s’accompagnent parfois d’exigences de sûreté et de sécurité, où la séparation des préoccupations est cruciale pour répondre à ces exigences. Cependant, s’appuyer sur des hyperviseurs soulève des problèmes de confiance et impose des contraintes supplémentaires lorsque des normes de sûreté et de sécurité, comme ISO 26262 ou ISO 21434, sont impliquées.

Une alternative aux hyperviseurs est l’implémentation d’un noyau de séparation dans un système d’exploitation temps réel. Cette approche permet de séparer les préoccupations au sein d’un système d’exploitation unique, garantissant une séparation au niveau de l’application au lieu d’une séparation au niveau du système d’exploitation. Examinons ces technologies un peu plus en profondeur.

L’hyperviseur embarqué : un superviseur pour les superviseurs

Un hyperviseur intégré est un logiciel qui permet à plusieurs systèmes d’exploitation de s’exécuter sur le processeur unique d’un appareil à ressources limitées, en partageant les ressources. L’hyperviseur sert de système d’exploitation pour les systèmes d’exploitation, leur permettant de partager les ressources CPU, mémoire et périphériques selon un schéma prédéfini. C’est-à-dire un superviseur pour les superviseurs, d’où le nom d’hyperviseur. Les hyperviseurs peuvent être dynamiques, avec un nombre de processeurs et une utilisation de la mémoire flexibles, ou statiques, avec des limites de processeur et une allocation de mémoire fixes. Les pilotes de périphériques peuvent être dédiés ou partagés entre différents systèmes d’exploitation. La figure 1 illustre une architecture d’hyperviseur typique pour la séparation.

L’introduction d’hyperviseurs dans l’architecture logicielle pour la séparation n’est pas sans défis car cela ajoute de la complexité. L’hyperviseur doit effectuer la séparation et la protection de la mémoire ainsi que la planification des différentes charges de travail. Il doit également gérer les niveaux de privilèges des systèmes d’exploitation invités virtualisés avec lui-même, tout en équilibrant l’accès aux ressources matérielles. L’hyperviseur devient alors le logiciel le plus privilégié du système.

Cet ensemble complexe de logiciels ajoute du code aux parties les plus critiques d’un système, s’exécutant au niveau de privilège le plus élevé du matériel. Par conséquent, la mise en œuvre de l’hyperviseur doit être sûre et sécurisée, sinon l’ajout d’hyperviseurs pour des améliorations en matière de sûreté et de sécurité ne sera pas vrai. Ainsi, l’ajout d’hyperviseurs avec une grande base de code dans la partie la plus sensible du système ajoute beaucoup de risques d’ajout de vulnérabilités. Par exemple, un regard sur un hyperviseur open source commun Xen et les vulnérabilités répertoriées de celui trouvé dans la base de données nationale des vulnérabilités montre plusieurs centaines de vulnérabilités répertoriées. Ce n’est pas un hyperviseur très fiable sur lequel s’appuyer pour essayer d’augmenter la sécurité du système en faisant de la virtualisation.

Le noyau de séparation logicielle : isoler les domaines sur un seul système physique

Le noyau de séparation logicielle, introduit par John Rushby dans un article de 1981, vise à créer un environnement qui ressemble à un système physiquement distribué. Il garantit que chaque domaine d’application apparaît comme une machine séparée et isolée, permettant aux informations de circuler uniquement le long des lignes de communication externes connues. Le noyau offre un haut niveau de sécurité en créant des domaines ou des partitions isolés sur un seul système physique. Il sépare strictement ces partitions, empêchant les logiciels d’une partition d’affecter les logiciels d’une autre. Cela protège l’ensemble du système contre les logiciels malveillants et les accès non autorisés.

Basé sur une architecture de micro-noyau, le noyau de séparation offre des services minimaux et s’appuie sur des services distincts pour des fonctionnalités supplémentaires. Cette conception réduit la surface d’attaque du noyau et améliore sa résistance aux compromis. Un noyau de séparation approprié fournit une isolation équivalente à l’isolation matérielle, ce qui le rend moins sensible aux vulnérabilités. Certains noyaux de séparation, tels que le micro-noyau L4, ont fait l’objet d’une vérification formelle pour garantir un fonctionnement correct. Il existe également des noyaux de séparation disponibles dans le commerce, tels que le système d’exploitation en temps réel INTEGRITY de Green Hills Software. Dans un environnement de système d’exploitation en temps réel à noyau de séparation, la séparation au niveau de l’application est représentée comme illustré à la figure 2.

Lors de l’exécution de plusieurs systèmes d’exploitation qui accèdent aux mêmes ressources, certaines implémentations peuvent avoir des problèmes de performances pour garder le système séparé. Par exemple, les hyperviseurs de type 1 auraient besoin de deux commutateurs de contexte pour exécuter une tâche critique lors de la réception d’une interruption. La première interruption est transmise à l’hyperviseur, puis traitée et transmise au système d’exploitation invité pour la planification des tâches. Une solution de noyau de séparation n’aurait besoin que d’une seule interruption pour permettre la planification d’une tâche critique. Bien que cela soit spécifique à l’implémentation, la virtualisation n’est pas toujours gratuite en termes de performances, notamment pour les tâches critiques ou pour accéder aux ressources partagées. Par conséquent, les performances du noyau de séparation et de l’hyperviseur peuvent être des considérations de conception importantes et nécessitent une architecture soignée pour les cas d’utilisation spécifiques dans les systèmes embarqués.

Pourquoi la séparation est-elle nécessaire ?

La séparation des préoccupations est nécessaire pour plusieurs raisons. Dans cette analyse, trois cas d’utilisation sont répertoriés :

• Sécurité : isolation de fonctionnalités spécifiques dans plusieurs instances du même système d’exploitation pour établir un accès sécurisé à des ressources spécifiques.
• Réutilisation de code ou systèmes hérités : utilisation de plusieurs systèmes d’exploitation différents pour réutiliser les fonctionnalités sans avoir besoin de réarchitecturer ou de réimplémenter.
• Criticité mixte : utilisation de plusieurs systèmes d’exploitation pour répondre aux normes de sûreté ou de sécurité qui nécessitent la séparation des applications.

Pour répondre à ces exigences, une solution d’hyperviseur est souvent envisagée. Cependant, une approche de noyau de séparation peut également répondre à ces besoins sans recourir à la virtualisation. Une analyse plus approfondie des trois cas d’utilisation différents avec un noyau de séparation à l’esprit nous donne ce qui suit.

Sécuriser l’accès à des ressources spécifiques

Si les méthodes de contrôle d’accès du système d’exploitation sous-jacent sont suffisamment sécurisées, un accès protégé aux ressources peut être obtenu au niveau de l’application. L’exploration de systèmes d’exploitation de noyau de séparation alternatifs au lieu de la virtualisation peut aider à éviter les pièges potentiels. De telles implémentations utilisent généralement des politiques de contrôle d’accès obligatoires pour y parvenir et peuvent utiliser des mécanismes de système d’exploitation pour partager en toute sécurité ces ressources, telles que des accès périphériques dédiés.

Réutilisation sans réarchitecture ni réimplémentation

Certains logiciels ne peuvent pas être rendus sûrs ou sécurisés en raison de facteurs indépendants du contrôle du projet, tels que des bibliothèques tierces ou des contraintes matérielles. Dans de tels cas, le logiciel doit être partitionné pour éviter toute interférence avec les exigences de sûreté et de sécurité du reste du système. Bien que la virtualisation soit une solution courante, elle ajoute une complexité inutile. Au lieu de cela, la modification sélective du code et la collaboration avec des fournisseurs tiers peuvent être plus efficaces, en particulier lorsque les noyaux de séparation offrent des couches de portabilité spécifiques. Ce cas d’utilisation est plus difficile à réaliser avec les noyaux de séparation, mais dans le but de rendre le système sûr et sécurisé, des modifications doivent être apportées.

Normes de sûreté ou de sécurité

Les normes de sécurité exigent souvent une séparation pour éviter toute interférence. Plutôt que d’introduire une couche de virtualisation complète, une autre couche de séparation répondant aux objectifs de la norme de sécurité peut suffire. L’utilisation d’une base de confiance plus petite pour la sûreté et la sécurité s’aligne sur les exigences de sécurité fonctionnelle. Par exemple, le noyau de séparation INTEGRITY RTOS de Green Hills Software est utilisé dans divers domaines tels que l’automobile, l’industrie et l’avionique, offrant plusieurs couches de sûreté et de sécurité.

La virtualisation n’est pas obligatoire

Les trois cas d’utilisation de la séparation peuvent ainsi être conçus sans virtualisation, en repensant l’architecture logicielle. La solution de noyau de séparation est capable d’héberger des applications avec des exigences de criticité mixtes sans avoir besoin d’un hyperviseur. Les couches de compatibilité des applications, telles que POSIX, les sockets TCP/IP et les interactions standard du système de fichiers, sont réalisées via des interfaces ouvertes.

Le noyau de séparation suit une architecture de micro-noyau et l’améliore en isolant les fonctionnalités, en mettant en œuvre un contrôle d’accès obligatoire aux périphériques et en fournissant une base pour une architecture logicielle alternative. Cette approche se traduit par une conception moins complexe avec une base de code plus petite, ce qui facilite la garantie de la sûreté, de la sécurité et de l’absence de bogues ou de vulnérabilités.

De plus, les noyaux de séparation permettent la coexistence d’applications à criticité mixte. Les principes d’un noyau de séparation imposent une phase de conception architecturale statique, alignée sur les meilleures pratiques en matière de systèmes de sûreté et de sécurité.

Pour obtenir des systèmes sécurisés, les ingénieurs logiciels doivent adopter un état d’esprit qui se concentre sur l’architecture des fonctionnalités en gardant à l’esprit la séparation. Des interfaces claires et protégées entre les applications et les services sont essentielles, et il est important de reconnaître qu’un service, tel qu’une bibliothèque ou un pilote de périphérique, peut être une application distincte dans le contexte des noyaux de séparation. Cela nécessite d’envisager des chemins architecturaux logiciels alternatifs pour obtenir une séparation appropriée pour la sûreté et la sécurité.

Résumé

En conclusion, les hyperviseurs intégrés et les noyaux de séparation peuvent répondre aux exigences de séparation pour la sûreté et la sécurité. Cependant, l’approche par défaut consistant à s’appuyer uniquement sur des hyperviseurs doit être remise en question. Envisager des noyaux de séparation avec une base informatique de confiance plus petite est un choix judicieux du point de vue de la sécurité, car les fonctionnalités fournies par les deux méthodes sont égales. Donner la priorité à une sécurité accrue dans la conception plutôt qu’à la réutilisation des logiciels suggère de remplacer les systèmes d’exploitation hérités ou de facto par des noyaux de séparation plus sécurisés qui s’appuient sur des couches de compatibilité, ce qui conduit à de meilleures conceptions de sûreté et de sécurité.

Marcus Nissemark est un ingénieur d’applications de terrain pour Green Hills Software, gérant l’équipe EMEA FAE. Avant de rejoindre Green Hills en 2014 en Suède, Marcus a travaillé comme architecte logiciel et développeur de produits embarqués depuis 1999. Ces produits comprenaient des contrôleurs et des ordinateurs d’affichage pour véhicules lourds, des équipements médicaux et militaires. Son expérience couvre plusieurs systèmes d’exploitation, le développement de pilotes de périphériques ainsi que les défis de gestion de processus et de produits dans le développement de logiciels.

Contenus connexes: