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
logo imprimer
Licence : CC by

 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

Notes :

[1Communications of the ACM, vol. 57 No. 1, pages 61-69

[2Engler, D. R., Kaashoek, M. F. and O’Toole, Jr., J. Exokernel : An operating system architecture for application-level resource management. In Proceedings of the 15th ACM Symposium on Operating Systems Principles, (1995), 251–266.

[3Leslie, I.M. et al. The design and implementation of an operating system to support distributed multimedia applications. IEEE Journal of Selected Areas in Communications 14, 7 (1996), 1280–1297.

P.S. :

On me signale le système Docker qui est disponible pour encapsuler des applications dans des containers autonomes et déployables à volonté.

Forum
Répondre à cet article
MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
I - le 22 juillet 2014

Salut,

C’est vraiment dommage et embêtant que MirageOS a été repris sans regarder si ça existait déjà (je parle du nom).
C’est un système qui existe déjà pour les TI, c’est un"shell" très puissant (relativement) : http://wiki.tiplanet.org/MirageOS

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
Laurent Bloch - le 22 juillet 2014

Calculatrices TI sur Z80 : cela me rajeunit, merci !

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
Fabrice Le Fessant - le 5 février 2014

L’idée n’est pas de faire un OS pour ordinateur, mais une application qui tourne dans le Cloud. Du coup, le choix est entre la technique habituelle (créer une VM, installer un OS genre Debian, installer l’application avec toutes ses dépendances, prévoir minimum 10 GB de disque juste pour l’OS et quelques GB de RAM par instance) et Mirage-OS, qui compile directement l’application dans une VM, prévoir quelques dizaines de MB de disque et quelques centaines de MB de RAM par instance...

Que ce soit d’un point de vue sécurité (pas de bugs venant de la distribution Linux, compartimentation des applications dans des VM scéllées) ou d’un point de vue performance (accès directement aux cartes réseaux, pas de context-switch coûteux), cela semble une très bonne solution...

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
Louis Pouzin - le 5 février 2014

En lisant l’article je voyais arriver la conclusion. On réinvente les premiers ordinateurs sans OS, où l’application faisait tout : IBM650, Bull Gamma ET, Apple ][. Pourquoi pas ?

MirageOS : retour à l’IBM 650 ?
Laurent Bloch - le 5 février 2014

Merci, Louis, de ta contribution. On peut aussi remarquer que si les OS de bibliothèques nous ramènent vers l’IBM 650, les FPGA nous ramènent à l’ENIAC, avec leurs mémoires locales pour chaque circuit : http://www.laurentbloch.org/MySpip3/spip.php?article279

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
- le 29 janvier 2014

Vive la modération a priori !
Bonjour,

J’ai du mal à saisir la nouveauté en dehors de la création d’un OS allégé facilement visualisable, intégré à l’application, sachant que pour être portable l’OS devra être écrit pour chaque hyperviseur.

De mémoire, quand on compile des applications on fait appel à des librairies soit statiques (embarquée dans le programme, gros le programme) soit dynamiques (présentes dans l’OS, maigre le programme). Un OS est une abstraction du matériel auquel l’application fait appel.

Avec MirageOS, certaines fonctions de l’OS sont renvoyées vers l’hyperviseur qui devient l’OS d’une application écrite pour l’OS MIrageOS (l’hyperviseur est l’abstraction du matériel).

J’ai l’impression qu’il y a quelque chose qui ne va pas, mon raisonnement, MirageOS ou ce qu’est devenue l’idée d’OS dans sa mise en oeuvre contemporaine ?

Merci de m’avoir lu
A bientôt
GM

MirageOS : machines virtuelles compilées à la demande avec le système d’exploitation et l’application
Laurent Bloch - le 29 janvier 2014

Bien sûr des éléments de réponse plus complets se trouvent dans l’article original, ou dans l’article publié en ligne ici : http://anil.recoil.org/papers/2013-asplos-mirage.pdf

L’idée est d’avoir des machines virtuelles ultra-légères, débarrassées des millions de lignes de code de l’OS qu’elles n’utiliseront pas, ce qui à l’heure du cloud est vraiment intéressant. En outre, le système de construction de ces VM permet de les recompiler facilement et vite. Cf. les articles originaux pour des explications plus détaillées.



pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.86.35