# Hyperviseur pour système embarqué

Les hyperviseurs pour systèmes embarqués désignent des dispositifs de virtualisation adaptés aux spécificités et aux contraintes des systèmes embarqués. Le fonctionnement de ces hyperviseurs diffère majoritairement en fonction de l'architecture de processeur, du cas d'utilisation et des besoins du système embarqué visé.
La recherche dans ce domaine s'est principalement développée au début des années 2010 afin de répondre aux nouveaux besoins des smartphones à la suite de la rapide évolution de leur capacité de calcul.
Malgré leurs différences de fonctionnement, les hyperviseurs destinés aux systèmes embarqués se retrouvent sur un certain nombre de concepts. Plusieurs technologies ont été proposées et parfois concrétisées pour les différentes architectures et cas d'utilisation des systèmes embarqués.

## Présentation générale
### Historique

L'intérêt pour la virtualisation des systèmes embarqués s'est réellement concrétisé lorsque les capacités techniques des smartphones se sont rapprochées de celles des serveurs et des ordinateurs de bureau$^,$$^,$.
Gernot Heiser (en) a défini en 2008 le rôle de la virtualisation des systèmes embarqués en montrant que ces derniers disposaient de caractéristiques de plus en plus proches des systèmes où la virtualisation est traditionnellement utilisée, tout en notant qu'ils conservaient certaines spécificités intrinsèques. Il présente les avantages pouvant être apportés par la virtualisation des systèmes embarqués, en citant principalement la sécurité. Il remarque cependant que l'architecture des systèmes embarqués impose certaines contraintes, notamment le besoin d'un partage efficace des ressources ainsi que d'une virtualisation simple, légère et dont l'empreinte soit la plus faible possible. Il propose pour cela une implémentation dédiée qui est OKL4, à base de micronoyau L4.
Par la suite, d'autres approches ont été proposées, telles que XtratuM (en) pour les systèmes critiques temps réel.
Certaines de ces approches se sont commercialement concrétisées, avec par exemple en 2009 le Motorola Evoke QA4 reposant sur un hyperviseur L4. Gernot Heiser a, à la suite de ses travaux de recherche, fondé Open Kernel Labs (en), une entreprise développant des hyperviseurs et des systèmes d'exploitation dédiés aux systèmes embarqués.

### Domaines d'application

La recherche sur la virtualisation des systèmes embarqués s'est principalement concentrée sur les smartphones$^,$$^,$$^,$$^,$.
Elle trouve cependant d'autres utilisations, par exemple dans le domaine de l'aéronautique et de l'astronautique, ou encore de l'automobile. Une autre application est celle du domaine médical.

### Enjeux

Par rapport aux systèmes où la virtualisation est traditionnellement utilisée, les systèmes embarqués ont certaines spécificités qui peuvent avoir une incidence sur leur potentielle virtualisation.
Parmi elles, on peut noter :
* des contraintes d'énergie : de nombreux systèmes embarqués reposent sur une batterie et disposent donc d'une source d'énergie limitée. L'hyperviseur ne doit donc pas ajouter une charge trop importante.
* une mémoire et une puissance de calcul encore relativement faibles.
* des besoins de sécurité :
** par exemple avec les smartphones, auxquels des données de plus en plus confidentielles sont confiées : données personnelles, paiement à l'aide de la technologie NFC, partage d'un smartphone entre une utilisation personnelle et professionnelle, etc. La sécurité du système ne doit pas être compromise ; la virtualisation pourrait au contraire être utilisée pour l'améliorer.
** dans le domaine de l'automobile, de l'astronautique ou de la médecine, où les responsabilités confiées aux systèmes embarqués sont critiques. L'ajout d'une couche de virtualisation ne doit pas compromettre la fiabilité du système déjà existant.
* une latence très faible : certains systèmes embarqués disposent de contraintes de temps réel. L'hyperviseur ne doit pas déséquilibrer l'ordonnancement du temps de calcul processeur ; certaines tâches critiques doivent pouvoir fonctionner immédiatement dans tous les cas.
* des architectures de processeur différentes : principalement les processeurs ARM, MIPS, PowerPC, ou encore x86 basse consommation. Les différences entre ces architectures peuvent induire des solutions de virtualisation totalement différentes$^,$$^,$.
* des cas d'utilisation différents : pour certains systèmes, la virtualisation apporte peu d'intérêt, ou le système est trop minimaliste pour que la virtualisation puisse être envisagée.

## Concepts

Plusieurs implémentations techniques ont été proposées et parfois concrétisées. Ces différentes approches se retrouvent cependant sur un certain nombre de concepts.

### Abstraction de l'architecture matérielle

La virtualisation permet de disposer d'une couche d'abstraction au-dessus du matériel ; ainsi, l'environnement de développement peut être vu comme une machine virtuelle, ce qui facilite sa maintenance par rapport à un environnement dépendant du matériel.
Ceci est d'autant plus pertinent dans le domaine des smartphones, où le matériel évolue rapidement, et où un même système d'exploitation peut être utilisé sur un matériel totalement différent (ce qui est par exemple le cas d'Android).

### Séparation des composants logiciels

Un des principaux avantages apportés par la virtualisation des systèmes embarqués est la possibilité d'isoler ses composants.
De cette façon, on peut avoir d'un côté le système d'exploitation temps réel (en anglais RTOS, pour Real-Time Operating System), et de l'autre un système d'exploitation utilisateur, gérant plutôt la partie applicative. De cette manière, une faille présente dans une application ne pourra avoir aucune incidence sur le RTOS.

### Communication intercomposants

Les systèmes virtualisés et l'hyperviseur doivent pouvoir communiquer entre eux de façon simple et efficace.
En effet, la plupart des systèmes embarqués ont des ressources limitées et disposent de contraintes de temps réel : l'hyperviseur ne doit donc pas prendre une part trop importante dans le temps de calcul processeur, et la méthode de communication entre les différents composants doit rester légère.

## Implémentations

La virtualisation des systèmes embarqués doit prendre en compte certaines limites et spécificités par rapport aux systèmes de virtualisation traditionnelle. Plusieurs approches techniques ont donc été proposées.

### Mésovirtualisation

La mésovirtualisation (traduction du terme original anglais mesovirtualization) est un concept de virtualisation légère proposé dès 2007 par Megumi Ito et Shuichi Oikawa.
Elle se dit minimaliste, dans le sens où l'hyperviseur est petit et où le système hôte n'a pas besoin de lourdes modifications. Elle se dit aussi performante, notamment car l'hyperviseur n'exécute qu'un nombre réduit d'instructions sur le processeur.
Cependant, la recherche sur la mésovirtualisation n'a jamais reçu d'application concrète. Elle ne concernait aussi que l'architecture x86.

### Xen

Xen est une solution de virtualisation populaire sur les ordinateurs de bureau et les serveurs.
Cependant, cette virtualisation repose principalement sur le fonctionnement de l'architecture x86. Les systèmes embarqués reposent plutôt sur d'autres processeurs tels que ARM. La présence d'instructions privilégiées sur cette architecture rend impossible l'utilisation de la technique trap and emulate de Xen$^,$.
L'utilisation d'une architecture Xen reste possible sur les systèmes embarqués, mais reste moins performante que ce que peut proposer L4. L'apparition d'instructions dédiées à la virtualisation dans certains processeurs ARM tels que le Cortex-A15 laisse cependant envisager une utilisation de Xen réellement adaptée aux systèmes embarqués.

### Architecture de type L4

L'approche de Gernot Heiser est d'avoir un hyperviseur le plus réduit possible, pour plusieurs raisons :
* par mesure de simplicité (ne pas ajouter de complexité supplémentaire) ;
* par souci de sécurité (un hyperviseur n'apporte de la sécurité que s'il est plus sécurisé que le système hôte) ;
* pour les performances et la réduction de consommation mémoire ;
* pour d'autres apports, tels que la vérification formelle.
Il propose donc une architecture à base de micronoyau L4, très performant et dont le coût de passage de messages est très faible.
Une comparaison entre cette architecture et une architecture Xen dans le cadre des systèmes embarqués a donné l'avantage à l'architecture L4 au niveau des performances et de la sécurité.

### XtratuM

Certains domaines d'application des systèmes embarqués, tels que l'aéronautique, font de la prévisibilité un élément critique.
L’hyperviseur XtratuM (en) a été élaboré spécialement pour des systèmes critiques temps réel qui utilisent des applications spatiales sécurisées basées sur le standard ARINC 653. C’est un hyperviseur bas niveau qui effectue un partage de la mémoire et du processeur, permettant ainsi à plusieurs applications de fonctionner indépendamment.
Il repose sur le principe de la paravirtualisation, qui est adaptée aux systèmes embarqués ayant des contraintes de temps réel.
XtratuM a été conçu pour l'architecture SPARC V8 du processeur Leon3.
XtratuM est conçu en trois couches :
* la couche liée au matériel : elle contient les pilotes nécessaires et est isolée du reste par la Couche d'abstraction matérielle.
* la couche du service interne : elle n’est pas accessible depuis les partitions. Elle contient la base de la bibliothèque standard du C et un ensemble de structures de données. Le programme d'amorçage en fait partie.
* la couche du service de virtualisation : elle permet aux partitions d’utiliser les services de paravirtualisation.
Une partition est un environnement d’exécution géré par XtratuM comprenant un ou plusieurs processus implémentés par un système d’exploitation. Les partitions disposent d’un accès aux ressources processeur déterminé par une durée fixe choisie en fonction de leur besoin. La planification de cycles alloue le temps nécessaire à chaque partition, une à la fois.
XtratuM fonctionne avec deux types de partitions : les partitions normales et les partitions systèmes. Les partitions normales sont limitées tandis que les partitions systèmes permettent de gérer et de surveiller l’état du système et des autres partitions$^,$.
Son architecture interne est composée :
* d'une gestion de la mémoire ;
* d'une planification de cycles fixes;
* d'une gestion d’interruption ;
* d'une gestion de l’horloge et des timers ;
* d'une gestion de la communication inter-partitions ;
* d'un mécanisme de surveillance ;
* d'un mécanisme de suivi.