Le concept de co-hébergement, ou co-hosting, permet de partager une plateforme ma-térielle entre plusieurs piles logicielles autonomes. Ces piles logicielles – OS généralistes, OS dédiés ou piles dédiées – sont considérées comme autonomes, car sur des plateformes traditionnelles – composées d’un ou plusieurs processeurs homogènes (symétriques) –, elles possèdent le contrôle complet de la plateforme. Dans ce cas, elles font généralement partie du TCB de la plateforme.
Comme expliqué dans la suite, les techniques actuelles de co-hébergement souffrent cependant de certaines limitations, en termes de sécurité ou de flexibilité.
2.3.1 Mémoire virtuelle
Le mécanisme de cloisonnement le plus répandu est incontestablement la mémoire vir-tuelle. Ce mécanisme permet en effet d’isoler des applications entre elles, en fournissant à chacune un espace d’adressage virtuel propre. La traduction de cet espace virtuel vers l’es-pace d’adressage physique de la plateforme est assurée par la MMU, qui est pilotée par un système d’exploitation. On est alors assuré qu’une application ne peut accéder illégalement aux segments mémoire appartenant à une autre application.
La MMU a la particularité importante d’être locale à un processeur, car traditionnel-lement intégrée physiquement à ce dernier. Cette caractéristique est un héritage fort du modèle d’architecture mono-processeur, dans lequel une unique pile logicielle autonome, généralement un OS, implémente la partie logicielle du TCB et couvre la plateforme ma-térielle. Cela signifie que cet OS s’exécute sur tous les processeurs de la plateforme et qu’il en contrôle alors toutes les MMU. Le partage de la mémoire physique entre les différentes applications est donc cohérent.
Si le mécanisme de mémoire virtuelle est performant pour isoler différentes applications logicielles s’exécutant au-dessus d’une unique base de confiance, il ne s’adapte pas du tout à une situation où plusieurs piles logicielles autonomes, par exemple plusieurs OS indépen-dants, fonctionnent simultanément sur la plateforme. En effet, un OS n’a absolument aucun pouvoir sur la MMU d’un processeur qu’il ne contrôle pas. Si plusieurs OS s’exécutent sur une plateforme, partageant les processeurs de manière exclusive, aucun d’entre eux ne peut contrôler entièrement l’espace adressable partagé en utilisant le mécanisme de MMU. En
2.3. CO-HÉBERGEMENT 21
outre, dans le cadre de plateformes hétérogènes, beaucoup de processeurs, voire la plupart, ne sont pas équipés de MMU.
La technique de mémoire virtuelle, via l’utilisation de MMU, est donc incapable de résoudre à elle seule la problématique de co-hébergement. On arrive aux mêmes conclusions avec l’utilisation d’une MPU, qui fournit un service de protection mémoire similaire à celui d’une MMU mais sans virtualisation de la mémoire (les applications fonctionnent dans l’espace d’adressage physique).
2.3.2 Partage statique des ressources
La technique la plus usitée pour résoudre le problème de co-hébergement consiste à partager de façon statique la plateforme, ou plus exactement les ressources de la plateforme.
Dans une telle approche, c’est à la conception que toutes les ressources sont attribuées définitivement aux différentes piles logicielles autonomes en présence : processeurs, zones mémoires, et périphériques adressables.
Dans le cas des processeurs, ce partage statique est intrinsèquement un partitionnement strict. C’est en effet l’hétérogénéité des processeurs qui dicte ce partitionnement entre les différentes piles logicielles autonomes. Partant de l’hypothèse que ces piles autonomes ne supportent pas l’hétérogénéité des processeurs, on ne pourra attribuer à une certaine pile autonome qu’un ou plusieurs processeurs du même type. De leur côté, les processeurs ne peuvent pas être partagés entre plusieurs piles autonomes car le mode le plus privilégié d’un processeur ne supporte toujours qu’un seul contexte d’exécution. L’attribution d’un ou plusieurs processeurs à une pile autonome est alors exclusive. En somme, le partitionne-ment exclusif des processeurs d’une plateforme hétérogène entre plusieurs piles logicielles autonomes est statique, dans le sens qu’il ne peut pas être modifié dynamiquement à l’exécution. Ici, et dans le reste du document, nous nous intéressons donc uniquement au partage de l’espace d’adressage, c’est-à-dire au partage de la mémoire et des périphériques adressables.
Dans cette approche, le découpage de l’espace d’adressage est uniquement spécifié théo-riquement. Il n’existe notamment aucun mécanisme matériel de type MMU ou MPU, comme nous pouvons le constater par l’illustration2.9, garantissant qu’une pile reste dans les limites fixées. Elle peut alors, par erreur ou volontairement si elle devient vérolée, ac-céder à des ressources qui ne lui étaient pas attribuées.
Il existe tout de même certaines manières de sécuriser un tel partage statique.
2.3.2.1 Sécurité
Une première méthode s’appuie sur l’architecture du système. Actuellement, les pla-teformes industrielles utilisent souvent une architecture basée sur un bus hiérarchique.
OS
App #1 App #2
Processeur #1 Processeur #2
Pile dédiée
Accès illégal réussi
Mémoire
App #2 App #1
OS
Pile dédiée
Accès illégal refusé
MMU
Figure 2.9 – Exemple de co-hébergement : une MMU peut isoler les applications s’exé-cutant sur le processeur dans lequel elle est intégrée, mais elle reste inopérante pour faire respecter le partitionnement des ressources aux autres processeurs.
Malgré une politique de mémoire partagée, il devient possible de restreindre l’accès à cer-taines ressources, c’est-à-dire cercer-taines zones de l’espace d’adressage, et par effet de bord, d’en sécuriser l’accès. Un banc mémoire ou un périphérique par exemple peuvent n’être uti-lisables que par un certain processeur car ils ne sont physiquement pas accessibles par les autres processeurs, le réseau d’interconnexion ne proposant pas de chemin pour l’atteindre. Cette technique n’est cependant qu’un détournement du principe de bus hiérarchique, et ne peut pas être utilisée de façon systématique.
Une autre méthode consiste à introduire des filtres d’accès, le plus souvent intégrés au réseau d’interconnexion ou placés comme des composants autonomes devant certains bancs mémoire. De tels filtres peuvent définir des associations de composants autorisés à communiquer entre eux. On peut ainsi garantir que le logiciel s’exécutant sur un certain processeur n’accède qu’aux composants qui lui ont été ouverts. Un autre type de filtre, souvent placé uniquement devant la mémoire externe, peut définir des zones mémoires que certains composants initiateurs de la plateforme ont le droit d’adresser. Le nombre de zones reste généralement assez limité, tout comme leurs possibilités de reconfiguration. Dans le cadre de systèmes orientés multimédia, on utilise donc souvent ce mécanisme pour confiner l’OS généraliste, plus sujet à d’éventuelles corruptions.
2.3.2.2 Flexibilité
De par sa nature statique, ce type de partage manque malheureusement de flexibilité, ce qui s’observe nettement sur deux aspects.