Si vous n’êtes pas familier avec le vocabulaire spécifique à Xen, je vous renvois vers l’article traitant de la terminologie Xen. Si vous ne connaissez pas bien le projet Xen, je vous renvois vers la présentation de ce projet.

Domaine non privilégié : domU

Les domaines non privilégiés sont communément appelés « domU » (U comme unprivileged). Les domU sont l’équivalent des systèmes d’exploitation invités sur les plateformes de virtualisation classiques. Concrètement, ce sont les machines virtuelles qui s’exécuteront sur votre plateforme Xen. Ces systèmes d’exploitation s’installent une fois que vous avez un hyperviseur et un dom0 fonctionnel. Il existe de nombreux outils vous permettant d’installer des domU de manière plus ou moins simple et rapide.

Comme vous le savez surement, Xen est capable de faire de la paravirtualisation mais aussi de la virtualisation matérielle assistée. A chacun de ces types de virtualisation correspond un type de domaine non privilégié. Les domU de paravirtualisation sont appelés « domU standards » et les domU de virtualisation matérielle assistée sont appelés « domU HVM ». L’acronyme HVM signifie « Hardware-Assisted Virtual Machine ».

domU de paravirtualisation : domU standard

Nous allons tout d’abord nous intéresser aux domU dits « standards ». Les domU de paravirtualisation sont considérés standards car il s’agit des premiers domU qui ont été disponibles pour Xen et les seuls jusqu’à la version 3.0. Ceci s’explique par le fait que la paravirtualisation est la raison d’être du projet Xen et ce qui en a fait un projet inédit.

Du fait qu’il s’agisse de domU de paravirtualisation, il est nécessaire que l’OS de chaque domU standard ait été adapté pour l’hyperviseur Xen. Ceci se fait par le biais d’API spécifiques supportant les hypercalls. De très nombreux systèmes d’exploitation peuvent être placés en tant que domU par dessus Xen. Tous les Linux sont compatibles ainsi que certains BSD et OpenSolaris.

domU de virtualisation matérielle assistée : domU HVM

Lorsqu’un système d’exploitation n’a pas été adapté pour Xen, il est nécessaire de recourir à une technique de virtualisation plus classique. Il s’agit bien évidemment de la virtualisation matérielle assistée. Ce type de domU permet à Xen de supporter la quasi totalité des systèmes d’exploitation existants pour l’architecture x86.

Le module utilisé par Xen pour effectuer les opérations de virtualisation matérielle assistée est le module QEMU. La contre partie des domU HVM est une perte de performances plus importante que dans le cas d’un domU standard. Ceci s’explique par le fait qu’il est nécessaire d’effectuer beaucoup plus d’opérations d’émulation.

Rôle des domU et délégation de périphériques

Les domU n’ont pas de rôle spécifique au niveau de la plateforme de virtualisation. Ils servent juste à exécuter les diverses applications qui sont contenues dans leurs systèmes d’exploitation. Il ne leur est accordé, par défaut, aucun privilège au niveau des ressources physiques. L’hyperviseur leur attribue une partie des ressources dynamiquement et les domU les utilisent ou pas en fonction de leurs besoins.

De plus, il est tout de même possible d’accorder quelques priviléges spécifiques aux domU. Ces privilèges spécifiques se matérialisent par la délégation de périphériques. Par exemple, il est possible de donner accès exclusif à un port USB ou PCI à un domU. Ceci va lui permettre de pouvoir utiliser un composant physique comme il le souhaite. Il y a eu des exemples de cartes graphiques déléguées à un domU permettant de jouer à un jeu 3D dans le domU. Notons tout de même que la délégation de périphérique à un domU restreint totalement sa mobilité entre plusieurs hyperviseurs ce qui peut être handicapant.

Au final, cette article présente les spécificités des domU. J’espère avoir été clair et compréhensible. Si ce n’est pas le cas, vous avez toujours la possibilité de laisser un commentaire pour me le signaler. En ce qui concerne la suite des événements, je suis encore indécis sur les sujets que je vais traiter. Cela devrait varier en fonction de mon prochain emploi. De toute manière, je souhaiterais parler plus des réseaux de stockage et du stockage en général.

J’ai déjà eu l’occasion de vous parler des domaines Xen à plusieurs occasions sur ce blog. J’ai défini la notion dans l’article sur la terminologie Xen. Dans ce billet je vais essayer d’élaborer un petit plus sur ce sujet en détaillant un peu plus les interactions entre le domaine privilégié et le matériel.

Domaine privilégié : dom0

Le domaine privilégié ou dom0 est le système d’exploitation « visible » d’une installation Xen. Il s’agit du système d’exploitation que l’on installe avant d’installer l’hyperviseur. Pour rappel, cela ne veut pas dire que l’hyperviseur est au desssus du dom0 car il est bien en dessous. Vous pouvez le vérifier au démarrage, car on voit bien que Xen s’exécute avant la distribution du dom0.

Le domaine privilégié est un domaine exceptionnellement sensible. Il s’agit du domaine qui va avoir accès à toutes les ressources physiques auxquelles l’hyperviseur n’aura pas l’accès exclusif. L’hyperviseur n’a un accès exclusif au processeur et à la mémoire. Tout le reste relèvera donc de la compétence du dom0. Ceci inclut donc tout particulièrement les supports de stockage. Le dom0 a donc accès à toutes les données de votre hyperviseur, il est donc indispensable de le sécuriser.

Le rôle du domaine privilégié

En ce qui concerne le rôle du dom0, il est essentiellement de gérer les supports de stockage, les périphériques éventuels ainsi que les éventuels interfaces d’administration. Il n’est pas souhaitable de lui attribuer plus de rôles que cela. Il est cependant indispensable de lui allouer des ressources physiques convenables. Etant donné que la gestion de support de stockage fait partie de sa compétence, il est nécessaire qu’il se voit attribuer suffisamment de mémoire vive afin de pouvoir constituer un cache performant.

L’hyperviseur attribue par défaut tous les périphériques au domaine privilégié. Certaines configurations spécifiques peuvent nécessiter de rendre accessible un périphérique à une machine virtuelle. Ces configurations sont relativement compliquées à mettre en place dans un contexte de haute disponibilité avec migration à chaud. Ceci s’explique habituellement par le simple fait que le périphérique ne peut être branché sur un seul serveur à la fois. Des solutions d’USB sur IP sont plus simples. Il reste cependant possible d’effectuer une délégation de périphérique vers un domaine non privilégié. Il y a déjà eu des exemples de délégation de cartes graphique permettant de jouer à des jeux 3D dans des domaines non privilégiés.

Interface avec les autres domaines

Les autres domaines vont accéder aux ressources relevant de la compétence du dom0 via des pilotes génériques de périphérique. Ces pilotes génériques permettent de maximiser la compatibilité et d’éviter les différences entre les différentes plateformes Xen. L’intérêt des pilotes génériques est immédiat dans le cas de la migration à chaud où la standardisation des environnements est primordiale.

Le schéma suivant récapitule très bien toutes ces interactions.

Au final, je pense avoir fait une présentation plutôt détaillée du domaine privilégié. Si vous avez des questions ou des remarques, n’hésitez pas, les commentaires sont faits pour cela. Dans un prochain article, j’évoquerais plus en détail les domaines non privilégiés.

Un barcamp aura donc lieu à la Halle Sportive de l’Université de technologie de Troyes ce Samedi à partir de 17 heures. Il aura lieu en marge de l’Utt Lan Session qui est une LAN Party organisée par l’Utt Net Group. Il devrait durer jusqu’à 22 heures environ. Une pause pour manger est prévue afin de pouvoir reposer vos neurones.

En ce qui me concerne, j’aurais l’occasion de vous faire une présentation « tour d’horizon » sur les réseaux de stockage. Vous pourrez également participer à de nombreuses autres présentations parmi les suivantes :

• VBA
• SOAP
• OpenID & OAuth
• OpenPGP
• LDAP
• CNIL
• Trap your process

N’hésitez pas à venir faire un tour et nous rencontrer ce weekend à Troyes. Vous trouverez toutes les infos nécessaires par rapport à cette manifestation sur le site de l’ULS.

Récapitulatif

• Quoi ? Un barcamp
• Quand ? Samedi 28 Novembre à partir de 17h jusqu’à 22h
• Où ? A la Halle Sportive de l’Université de technologie de Troyes
• Pour qui ? Tout le monde qui souhaite partager avec nous

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

A travers une erreur de frappe, je me suis retrouvé à découvrir quelques « mystères » par rapport à cette commande. Je tiens à remercier mon collègue Laurent et son erreur de frappe qui nous a permis de découvrir ces « mystères ». Ils ont été testés sur Windows XP et Linux.

L’utilisation habituelle de la commande ping ressemble à la commande suivante et vous donne le résultat indiqué.

root@serveur:~ # ping 10.2.0.10

PING 10.2.0.10 (10.2.0.10): 56 data bytes

64 bytes from 10.2.0.10: icmp_seq=0 ttl=255 time=0.173 ms

64 bytes from 10.2.0.10: icmp_seq=1 ttl=255 time=0.134 ms

— 10.2.0.10 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.134/0.153/0.173/0.000 ms

Premier mystère

Vous avez déjà surement fait des fautes de frappe en tapant cette commande, mais avez-vous déjà regardé le résultat que cela produit ? Voici un exemple du ping vers l’IP 10.2.017.

root@serproxy01:~ # ping 10.2.017

PING 10.2.017 (10.2.0.15): 56 data bytes

64 bytes from 10.2.0.15: icmp_seq=0 ttl=255 time=0.824 ms

64 bytes from 10.2.0.15: icmp_seq=1 ttl=255 time=0.525 ms

— 10.2.017 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.525/0.674/0.824/0.150 ms

On pourrait s’attendre à ce que la commande ping nous retourne un erreur. La syntaxe de l’écriture de l’adresse IP que nous avons saisie est cependant mauvaise… Vous pouvez essayer avec n’importe quelle IP, cela fonctionne de manière similaire. Nous voyons qu’un ping vers la 10.2.017 effectue en réalité un ping vers l’adresse 10.2.0.15. Un ping vers l’adresse 10.2.0.15 aurait été tout à fait logique mais ce n’est pas le cas. Quel est donc le lien entre 10.2.017 et 10.2.0.15 ? Je vous laisse essayer avec différentes IP afin d’essayer de trouver le lien logique.

Explication

Vous avez trouvé ? J’espère bien. Les plus futés d’entre vous auront remarqué que 017 correspond à 15 en base 8 ou octal. Pour la petite explication :

0 x 64 + 1 x 8 + 7 x 1 = 8 + 7 = 15.

Second mystère

Nous avons donc réussi à percer ce premier mystère. Alors que nous étions en train de chercher la solution au premier, nous avons rencontrer une seconde bizarrerie. Essayez la commande ping 10.3.2947 et remarquez le résultat produit.

D:\Documents and Settings\Administrateur>ping 10.3.2947

Envoi d’une requête ‘ping’ sur 10.3.11.131 avec 32 octets de données :

Réponse de 10.3.11.131 : octets=32 temps<1ms TTL=128

Statistiques Ping pour 10.3.11.131:

Paquets : envoyés = 1, reçus = 1, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms

Dans la même veine, nous pouvons essayer la commande ping 10.199449 et observer le résultat.

D:\Documents and Settings\Administrateur>ping 10.199449

Envoi d’une requête ‘ping’ sur 10.3.11.25 avec 32 octets de données :

Réponse de 10.3.11.25 : octets=32 temps<1ms TTL=128

Réponse de 10.3.11.25 : octets=32 temps=1 ms TTL=128

Statistiques Ping pour 10.3.11.25:

Paquets : envoyés = 2, reçus = 2, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 1ms, Moyenne = 0ms

Après le premier mystère, on commence à comprendre que la commande ping agit selon une logique étrange. Vous remarquerez qu’il ne s’agit plus, cette fois-ci, de base 8. Une fois de plus, cela fonctionne avec n’importe quelle IP formatée selon ce mode. On voit facilement qu’on n’est plus en base 8 car le chiffre 9 ne nous renvoie pas d’erreur particulière. Je laisse chercher les plus intrépides d’entre vous. Les autres, vous pouvez continuer à lire cet article.

Vous avez trouvé ? Vous en êtes bien sur ? Les plus futés d’entre vous auront remarqué que nous ne sommes plus en base 8 mais en base 256. Pour démontrer ce fait, je ferais appel à la division avec reste entier.

Explication

Reprenons le premier exemple :

2947 / 256 = 11 reste 131.

Etant donné le préfixe 10.3, vous avez donc 10.3.11.131.

Reprenons le second exemple :

199449 / (256 x 256) = 3 reste 2841

2841 / 256 = 11 reste 25

Nous avons donc 10.3.11.25. Pour vous en convaincre, vous pourrez voir que :

256 x 256 x 3 + 256 x 11 + 25 = 199449.

Au final, j’espère que cet article vous a plu et vous a un peu retourner le cerveau, car s’en était bien l’objectif. Vous ne verrez plus la commande ping de la même manière désormais.

Par le biais de ce billet, je souhaite faire un point sur tous les termes qui sont utilisés très fréquemment lorsque nous sommes amenés à parler du projet Xen. J’ai essayé de faire une première liste. Si jamais vous en voyez d’autre, n’hésitez pas à me le faire remarquer et je les rajouterais ici.

Domaine – Un domaine est une machine virtuelle. Le projet Xen a choisi de s’affranchir de la notion de machine virtuelle car cela avait tendance à renvoyer vers les techniques conventionnelles de virtualisation totale.

• Domaine privilégié ou dom0 : Le domaine 0 qui correspond au système d’exploitation installé initialement sur le matériel physique. Ce domaine dispose de tous les outils pour gérer les paramètres de l’hyperviseur et l’état des autres domaines
• Domaine non privilégié ou domU : Il s’agit d’un domaine standard qui correspond à la définition conventionnelle de la machine virtuelle mais transposée dans le monde de la paravirtualisation.

Hyperviseur – L’hyperviseur est la première interface entre le matériel et les couches applicatives. Il n’est pas positionné par dessus un système d’exploitation hôte. VMWare utilise le terme d’hyperviseur alors qu’il s’agit d’une application inclue dans un système d’exploitation hôte. Je n’utiliserais que la définition de l’hyperviseur au sens de Xen sur ce blog.

PV – Il s’agit là de l’abréviation de paravirtualisation. Il sera souvent évoqué la notion de « domaine PV » ce qui correspond à un domaine interfacé avec l’hyperviseur via l’API Xen.

HVM (Hardware Virtual Machine) – Le HVM est l’appellation de la virtualisation matérielle assistée dans le projet Xen. Le projet Xen est donc capable de faire de la paravirtualisation et de la virtualisation matérielle assistée. Typiquement, le HVM permet d’exécuter des domaines Windows. Le module de virtualisation matérielle assistée est une version modifiée de QEMU.

VIF (Virtual Interface) – Une VIF est une interface réseau virtuelle par opposition aux interfaces réseau physiques. Ces interfaces servent à mettre à disposition une interface réseau aux domaines. Les interfaces virtuelles seront ensuite reliées par divers méthodes (Pont, NAT, Routage) aux interfaces physiques.

XM (Xen Management) – Xen Management est le jeu d’outils qui permettent de passer des commandes à l’hyperviseur au niveau du dom0. Il permet notamment d’exécuter, de mettre en pause et de couper les différents domaines présents sur la machine. Pour plus d’informations, n’hésitez pas à saisir la commande « xm help ».

GPLPV – Les drivers GPLPV sont les drivers qui permettent d’ajouter des extensions de paravirtualisation à des domaines HVM. L’objectif de ces drivers est d’améliorer les performances des domaines HVM. Les drivers GPLPV sont comparables aux VMWare Tools.

Au final, je pense avoir fait un petit tour des termes les plus utilisés dans les ressources évoquant le projet Xen. J’espère que ce billet permettra à quelques personnes de mieux comprendre le projet Xen et de, pourquoi pas, se lancer dans une installation.

Nous avons vu précédemment les trois contraintes imposés au VMM par leur théorie. Pour rappel, le VMM (Virtual Machine Monitor) est la couche applicative de virtualisation.  L’objectif de leur théorie est d’établir les pré-requis nécessaires à la virtualisation. Les trois contraintes servent de base à ces pré-requis et sont en quelque sorte les pré-requis élémentaires. La suite de leur papier s’attache à énoncer des règles plus spécifiques quand à ces pré-requis.

Trois groupes d’instructions processeur

Ils ont tout d’abord distingué trois groupes d’instructions processeur. Leur théorie étant plutôt générique, ces instructions ne sont pas mentionnées nominativement. Elles sont évoqués par leur comportement. Le processeur dispose de deux modes d’exécution : le mode utilisateur et le mode privilégié. Les instructions « utilisateur » sont les instructions classiques de calcul alors que les instructions « privilégiées » sont les instructions de manipulation de données.

Le premier groupe d’instructions processeur est le groupe des instructions privilégiées. Ces instructions nécessitent donc que le processeur soit en mode privilégié pour être exécuté. Si ce n’est pas le cas, elles sont « piégées » (de l’anglais trap) par le système afin d’être traités par le VMM. Le « piège » consiste en un changement de contexte et un traitement de l’instruction par le VMM qui décidera de la suite à donner à cette instruction. Il peut soit l’ignorer soit émuler son fonctionnement.

Le second groupe d’instructions processeur est le groupe des instructions sensibles à la configuration. Ces instructions qui va modifier la configuration du système physique. Ce groupe inclut les instructions visant à à modifier la quantité de mémoire disponible à un processus ou celles visant à changer le mode du processeur sans être « piégées ».

Le troisième groupe d’instructions processeur est le groupe des instructions sensible au comportement. Il s’agit des instructions dont le comportement est impacté par la localisation son exécution. Ce groupe inclut les instructions visant à lire une zone de mémoire vive spécifique ou à se déplacer dans la mémoire vive.

Les trois théorèmes

Après avoir posé tout ces pré-requis, ils énoncent ensuite le coeur de leur théorie, à savoir les théorèmes. Le premier théorème porte sur la possibilité de virtualisation une architecture processeur. Le second théorème porte sur la possibilité de faire de virtualisation récursive, à savoir faire fonctionner plusieurs machines virtuelles dans une machine virtuelle. Le troisième porte sur la possibilité d’exécuter des HVM (Hybrid Virtual Machine) sur une architecture processeur. Un HVM au sens de Popek & Goldberg est une VM pour laquelle une majorité d’instructions sont interprétées par le VMM.

Le premier théorème énonce que pour qu’une architecture processeur soit virtualisable il faut que les instructions sensibles fassent parti des instructions privilégiés.

For any conventional third generation computer, a virtual machine monitor may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions.

L’architecture la plus répandue actuellement ne répond pas à ce théorème, il y a quelques instructions qui posent problème d’où la nécessité d’utiliser les techniques de virtualisation que nous connaissons aujourd’hui.

Le second théorème énonce qu’il est possible de faire de la virtualisation récursive sur une architecture processeur si elle répond au premier théorème et qu’un VMM sans dépendance de temps peut être élaboré.

A conventional third generation computer is recursively virtualizable if it is : virtualizable and a VMM without any timing dependencies can be constructed for it.

Le troisième théorème énonce  qu’un HVM est réalisable si les instructions sensibles exécutables en mode utilisateur font partie des instructions privilégiées.

A hybrid virtual machine monitor may be constructed for any conventional third generation machine in which the set of user sensitive instructions are a subset of the set of privileged instructions.

Au final, je pense avoir fait le tour de la théorie de Popek et Goldberg. Je suis conscient que ce sujet est assez compliqué à appréhender. Je ne pense pas avoir été d’une clarté légendaire mais j’espère avoir clarifié quelque peu cette théorie. Si vous souhaitez en savoir plus sur cette théorie, je vous invite à lire le document initial (maitrise de l’anglais requise).

La naissance de la virtualisation

Tout d’abord, la virtualisation est un concept ancien à l’échelle de l’informatique. Ce n’est pas VMWare qui a inventé la virtualisation en 1999 avec leurs applications. La virtualisation totale n’est pas non plus le premier type de virtualisation. La virtualisation est un concept qui date d’au moins 1970, année à laquelle vous n’étiez (probablement) pas né.  A cette époque est arrivé la révolution des ordinateurs IBM System/360 qui étaient exceptionnels par le fait qu’ils étaient compatibles à l’intérieur d’un même gamme. Un System/360 ressemble à la photo suivante :

A cette époque, la virtualisation se faisait de manière matérielle avec un cloisonnement électronique des divers composants applicatifs. Ce type de virtualisation semble toujours exister aujourd’hui dans certains mainframes.

Popek et Goldberg

Popek et Goldberg sont deux chercheurs en informatique de cette époque. Ils ont souhaité formuler les pré-requis nécessaires à la virtualisation de manière formelle. Ils définissent plusieurs termes que l’ont connait toujours aujourd’hui. Une « VM » est une « Virtual Machine » ou machine virtuelle. Un VMM est un « Virtual Machine Monitor » ou moniteur de machine virtuel. Ce dernier correspond à la couche de virtualisation. Ce terme est peu utilisé mais il est possible de le retrouver occasionnellement.

Trois contraintes imposées au VMM

Ils ont tout d’abord défini trois critères que doivent remplir les systèmes de virtualisation afin de pouvoir être considéré en tant que tel. Ces critères serviront par la suite à définir les théorèmes de leur théorie.

Le premier critère est le critère « équivalence». Ce critère implique qu’une application quelconque doit s’exécuter de la même manière qu’elle soit exécuté au dessus d’un VMM ou d’une machine physique. Ceci est nuancé par la disponibilité des ressources physiques qui peuvent modifier la temporalité de l’exécution d’un programme.

Any program run under the VMM should exhibit an effect identical with that demonstrated if the program had been run on the original machine directly, with the possible exception of differences caused by the availibility of system resources and differences caused by timing dependencies.

Le second critère est le critère « efficacité». Ce critère indique qu’une part majoritaire d’instructions soit exécutée par le processeur directement sans intervention du VMM. Ce critère exclut donc les émulateurs et les techniques de virtualisation totale. La virtualisation matérielle assistée permet de répondre plus correctement à ce critère.

The second characteristic of a virtual machine monitor is efficiency. It demands that a statiscally dominant subset of the virtual processor’s instructions be executed directly by the real processor, with no software intervention by the VMM.

Le troisième critère est le critère  « contrôle de ressources». Ce critère indique que le VMM doit avoir le contrôle exclusif des ressources à partager. N’importe quelle application doit donc passer par la VMM pour pouvoir accès à une ressource partagée.

The VMM is said to have complete control of these resources if it is not possible for a program running under it in the created environment to access any resource not explicitly allocated and it is possible under certain circumstances for the VMM to regain control of resources already allocated.

Ces trois critères servent de base à la suite de leur papiers énonçant leurs théories. Nous verrons dans un prochain billet la suite des théorèmes.

Si vous avez lu mon précédent billet sur la virtualisation matérielle assistée, vous avez dû remarquer que je parlais de l’ajout de l’anneau « -1″. Sauf qu’un précédent billet sur les anneaux de protection système n’évoquait que les anneaux de 0 à 3.

L’architecture historique, à savoir, l’architecture x86-32 dispose effectivement de 4 anneaux numérotés de 0 à 3. Cependant seuls deux anneaux étaient utilisés : un pour le système d’exploitation et un pour les applications. Lorsqu’AMD et Intel ont refondu l’architecture x86 pour passer au 64-bit, ils ont décidé de supprimer les anneaux 1 et 2. Il ne resta donc plus que les anneaux 0 et 3.

Ceci n’a pas créé de problème particulier car ces anneaux n’étaient pas utilisés dans les systèmes d’exploitation. La virtualisation est arrivée relativement peu de temps après et avait pour habitude d’utiliser un anneau supplémentaire afin de cloisonner l’hyperviseur, le système d’exploitation et les applications. Les solutions de virtualisation se sont donc retrouvées avec deux anneaux alors qu’il était plus simple et plus sécurisé d’en utiliser trois. Afin de résoudre cette problématique, dans le cas du projet Xen, l’anneau 3 a été mutualisé pour les applications et les systèmes d’exploitation. Il a été préféré de cloisonner seul l’hyperviseur. Cette disposition donne le schéma suivant :

Par la suite, AMD et Intel se sont rapidement rendus compte de l’importance que commençait à prendre la virtualisation. Ils ont donc décidé d’inclure dans leurs processeurs des instructions de virtualisation facilitant les opérations liées à cette technique. Ces extensions ont rendu possible la virtualisation matérielle assistée comme je l’ai évoqué précédemment. En même temps, il a été ajouté un anneau « -1″ qui permet à la paravirtualisation d’éviter la mutualisation de l’anneau 3. Ceci a permis de revenir à une disposition plus propre des composants applicatifs parmi les anneaux de protection système. Le schéma ci-dessous illustre la nouvelle disposition.

Avant de pouvoir continuer sur la virtualisation, je souhaite faire un article qui servira de pré-requis à la suite. Je vais parler des anneaux de protection (ou rings pour les anglophones). Cette notion n’est pas seulement utile en virtualisation mais plus largement en systèmes d’exploitation.

Principe des anneaux de protection

Vous avez surement entendu parlé de « Rings » ou d’anneaux si vous avez déjà fait un peu de sécurité des systèmes d’exploitation, de la virtualisation ou de l’électronique informatique. On parlera ici d’anneau de protection afin d’éviter les termes anglophones, nous parlons en Français tout de même. Comme vous commencez sans doute à vous en douter, nous serons ici sur du « bas niveau » au niveau des systèmes d’exploitation.

Nous étudierons tout d’abord l’utilité des anneaux de protection. Comme leur nom l’indique, ils ont pour objectif de fournir une fonction de protection. Cette protection s’applique sur les divers composants applicatifs du système d’exploitation. L’objectif va être d’empêcher divers composants applicatifs d’un système d’exploitation de se modifier entre eux. Vous comprendrez donc qu’une modification d’un composant applicatif par un autre est synonyme de faille de sécurité.

Les composants qui vont nous intéresser plus particulièrement dans le cadre d’un système d’exploitation sont le noyau et les applications. Autant il est tout à fait envisageable que le noyau puisse apporter des modifications aux données dynamiques d’une application, l’inverse l’est beaucoup moins. Ces données dynamiques sont les données stockées en mémoire vive. La mémoire vive est systématiquement amenée à contenir le programme lui-même ainsi que les données qu’il traite. Vous comprenez donc bien l’intérêt d’une protection ou plutôt d’un cloisonnement.

Application aux systèmes x86-32

Dans les systèmes x86-32, il existe 4 anneaux de protection numérotés de 0 à 3. Dans la quasi-totalité des systèmes d’exploitation sans virtualisation, seuls les anneaux 0 et 3 sont utilisés. L’anneau le plus privilégié est l’anneau 0 qui contient le noyau du système d’exploitation. L’anneau le moins privilégié est l’anneau 3 qui contient les applications et leurs données dynamiques. Les deux autres anneaux ne sont pas utilisés. Ils l’ont été dans OS/2 ou bien Netware pour y placer différents pilotes. Le schéma ci-dessous reprend la répartition des composants applicatifs dans un système d’exploitation moderne.

Application à la paravirtualisation

Dans le cadre de la paravirtualisation, le système d’exploitation ne sera pas le premier intermédiaire du matériel mais ce sera l’hyperviseur. Pour des raisons de sécurité, il sera nécessaire de cloisonner le système d’exploitation et l’hyperviseur. Dans ce cas-là, il sera fait usage de l’anneau 1. Nous placerons donc l’hyperviseur dans l’anneau 0 et le système d’exploitation dans l’anneau 1. Les applications restent bien au chaud dans l’anneau 3.

Implémentation des anneaux de protection

Maintenant que je vous ai expliqué tout ceci, l’utilité et l’application des anneaux de protection semble clair. Il manque cependant un élément clé de la compréhension de ce concept : l’implémentation des anneaux de protection. Comment se concrétisent les anneaux de protection ? Où se trouvent-ils dans la nature ?

Les anneaux de protection sont implémentés au niveau de la mémoire vive. Une zone de mémoire vive se voit attribuer une localisation dans un anneau par le système d’exploitation. Un programme contenu dans une zone mémoire attribuée à l’anneau 3 ne pourra pas aller modifier une zone mémoire attribuée à l’anneau 0.