Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
Un article d’Anil Madhavapeddy et David J. Scott
Article mis en ligne le 29 janvier 2014
dernière modification le 5 février 2014

par Laurent Bloch

Machines virtuelles et hyperviseur, petit rappel

Un article précédent de ce site expliquait pourquoi et comment la technologie des machines virtuelles (VM) était essentielle pour l’informatique en nuage. En résumé, une machine virtuelle est un logiciel qui simule le comportement d’un ordinateur physique. En interposant entre une machine physique et une machine virtuelle un système d’exploitation simplifié nommé hyperviseur, on permet à la machine virtuelle d’accéder aux ressources matérielles de la machine physique par le biais de simulacres des dispositifs matériels habituels : interface réseau, clé USB, clavier, écran, souris, etc. Ceci fait, on peut installer sur la machine virtuelle un système d’exploitation, auquel on présentera les simulacres de clés USB, prise réseau, etc., alors qu’en fait, tout ce à quoi il aura réellement accès, ce sera un espace de mémoire (virtuelle !) et du temps de processeur. Le système d’exploitation (OS) de la machine virtuelle sera dit « système invité ». Et sur une machine physique avec un seul hyperviseur, rien n’interdit de faire fonctionner plusieurs machines virtuelles, éventuellement avec des OS invités différents (Linux, Windows, FreeBSD...).

Ce système génial réalise une abstraction du matériel : seul l’hyperviseur a besoin de savoir piloter tous les dispositifs matériels dont il apparaît chaque jour de nouveaux modèles chez les fournisseurs. Ce sera ensuite l’hyperviseur qui fournira aux machines virtuelles le simulacre convenable pour communiquer avec le matériel réel. Ainsi, l’apparition d’une nouvelle technologie de disques, SSD par exemple, impose la programmation de nouveaux pilotes pour l’hyperviseur, mais celui-ci pourra continuer à présenter aux systèmes invités une interface ancien modèle, puisque tout ce qui importe c’est de leur fournir les flux de données qu’ils s’attendent à recevoir, sans se préoccuper du traitement, infiniment complexe et variable, des signaux physiques de la transmission.

Un logiciel, une VM, un OS sur mesure, compilés ensemble, en langage fonctionnel

Peut-on aller plus loin ? C’est ce que nous expliquent, dans un article des Communications of the ACM [1] intitulé Unikernels : The Rise of the Virtual Library Operating System, Messieurs Anil Madhavapeddy et David J. Scott, qui travaillent sur le sujet depuis une dizaine d’années, du côté de Cambridge (UK) et chez Citrix. Si on n’est pas abonné aux CACM, on pourra lire en ligne une version préliminaire de cet article.

Puisque l’on peut multiplier les machines virtuelles à volonté, sans coût important, sans manipulation physique et sans délai, on peut en profiter pour avoir une VM pour chaque logiciel utilisé, pour chaque application métier par exemple.

Puisque chaque OS invité n’exécute qu’une seule application, est-il nécessaire qu’il soit muni de tous les dispositifs ultra-complexes destinés à garantir l’étanchéité des espaces de mémoire et de données de chaque application, tout en leur permettant de communiquer entre elles lorsqu’il le faut ? Ces fonctions d’isolation et de communication seront assurées, bien plus efficacement et bien plus simplement, par l’hyperviseur. Il est donc possible de les retirer du système invité.

Puisqu’en outre cet OS invité n’aura pas à piloter toute une variété de dispositifs physiques complexes et changeants, mais seulement quelques périphériques simulés ultra-simplifiés et stables, il sera allégé des fonctions correspondantes.

Et puisque seront éliminés la plupart des risques liés aux accès directs au matériel et à la cohabitation de logiciels entre lesquels il faut éviter les interférences, il ne sera plus utile d’avoir une distinction entre le mode superviseur et le mode utilisateur, ni entre la mémoire du noyau et l’espace mémoire des utilisateurs.

Après toutes ces simplifications, les OS invités pourront se présenter sous forme de simples bibliothèques de fonctions, qui seront compilées et liées avec les logiciels d’application.

Et tant qu’à faire, on écrira toutes ces bibliothèques dans un langage fonctionnel de haut niveau, ce qui facilitera considérablement le développement, et réduira le risque d’apparition de vulnérabilités telles que les débordements de buffer, inévitables en programmation de bas niveau, et toujours en tête du hit-parade des CERT.

En l’occurrence, le langage choisi par nos auteurs est OCaml, un logiciel libre dont, soit dit en passant, l’équipe de conception et de développement est née en France autour de Xavier Leroy.

Unikernel : avantages et inconvénients

La technologie qui consiste à compiler une application avec les morceaux de système d’exploitation dont elle a besoin, et uniquement ceux-là, se nomme Unikernel. ou library operating system (libOS). Nos auteurs citent les premières avancées sur ce terrain à la fin des années 1990, Exokernel [2] et Nemesis [3].

Un des avantages majeurs du fait d’avoir l’application et les fonctions système dans le même espace mémoire, sans séparation des privilèges, consiste à éviter d’avoir à copier sans cesse des données de l’espace utilisateur à l’espace noyau et en sens inverse. De plus, les applications ont accès directement aux dispositifs matériels, sans l’intermédiaire du noyau, ce qui améliore les performances.

En contrepartie, expliquent nos auteurs, Nemesis et Exokernel ont rencontré deux obstacles majeurs : la difficulté d’isoler chaque application de ses voisines, et la nécessité d’écrire des pilotes pour chaque dispositif matériel nouveau. Or, justement, ces deux difficultés sont résolues par le recours aux machines virtuelles, puisque c’est l’hyperviseur qui fournira les pilotes et qui assurera le cloisonnement des VM. C’est ce dont ont tiré parti nos auteurs, en profitant des progrès des techniques de virtualisation, et aussi de ceux des processeurs, qui permettent aujourd’hui d’utiliser ces techniques avec des performances décentes.

Un commentaire de lecteur (cf. en bas de la page) mentionne, au titre des inconvénients, la nécessité de recompiler MirageOS pour chaque type d’hyperviseur. Certes, mais il faut noter que les principaux éditeurs de systèmes de virtualisation (qui, soit dit en passant, se comptent sur les doigts d’une seule main) se sont entendus sur des formats de données publiés. La Distributed Management Task Force (DMTF ; http://dmtf.org/) a publié l’Open Virtualization Format, ou OVF, une spécification adoptée par les principaux éditeurs (tels que Citrix, Microsoft et VMware) et acceptée comme norme en août 2010 par l’American National Standards Institute (ANSI ; http://ansi.org/).

Au nombre des avantages procurés par un OS basé sur des bibliothèques de fonctions et compilé avec les seuls modules qui seront utiles à l’application à laquelle il est dédié, il y a une sécurité accrue. En effet, un tel OS, très allégé, offrira à l’assaillant une surface d’attaque beaucoup plus réduite qu’un OS généraliste de 30 millions de lignes de code, sans compter le navigateur Web et le système de gestion de bases de données (SGBD).

MirageOS

Anil Madhavapeddy et David J. Scott ont baptisé leur système MirageOS, un nom qui convient bien à un OS destiné à animer des machines virtuelles dans les nuages.

La construction d’une application avec MirageOS commence avec la création d’un graphe de dépendances pour identifier les ressources nécessaires. En effet, une VM classique embarque un système d’exploitation complet, sans oublier un serveur Web, un système de gestion de bases de données et un système de gestion de fenêtres, qui doivent chacun lire leurs fichiers de configuration au démarrage pour s’initialiser, alors que seule une petite partie de leurs fonctions seront utilisées par l’application déployée. Le but d’un Unikernel tel que MirageOS est d’élaguer ces processus pour ne charger et configurer que les fonctions utiles. C’est d’ailleurs pourquoi les fichiers de configuration sont inclus d’emblée dans le graphe de dépendances, et chargés lors de la compilation de l’application. Il en va de même des parties utiles du noyau, disponibles sous formes de bibliothèques dans les entrepôts de code source OCaml. Signalons par exemple que la bibliothèque d’exécution d’OCaml comporte une pile TCP/IP complète, ce qui signifie que la machine virtuelle MirageOS n’aura à demander les services réseau de l’hyperviseur qu’au niveau de la couche 2 (Ethernet).

À la date de rédaction de l’article, MirageOS comporte une centaine de bibliothèques (en open source) qui réalisent un large éventail de fonctions attendues du noyau d’un système d’exploitation. Son portage dans des systèmes commerciaux, tels que XenServer de Citrix, est en cours.

Il est difficile de prévoir l’avenir de MirageOS : l’histoire de l’informatique est pavée d’excellentes idées (et d’excellentes réalisations) supplantées par des systèmes bien moins bons. Une vision aussi révolutionnaire aura à surmonter le conservatisme des entreprises et, surtout, de leurs ingénieurs. Mais il ne fait aucun doute que les évolutions récentes de l’informatique, notamment en nuage, sont un appel à ce type de solutions.

Commentaires des lecteurs