Catégorie : Virtualisation

Les anneaux de protection système dans le cas du 64-bit

Antoine

800px-Olympic_Rings.svgDans le billet précédent, j’ai eu l’occasion de vous présenter les anneaux de protections système et leur utilité dans le cas de la virtualisation. Je vais continuer avec ce billet évoquant les spécificités du 64-bit.

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 :

Rings64bit

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.

Rings64bitImproved

Les anneaux de protection système

Antoine 3 commentaires

800px-Olympic_Rings.svgLa série d’articles sur la détection d’intrusion m’aura permis de faire une petite coupure dans la série d’articles sur la virtualisation. Je vais donc reprendre les articles sur la virtualisation. Pour rappel, la plupart des ces articles sur la virtualisation reprennent le contenu de l’AC que j’ai effectué avec Romain Hinfray. Ces articles me permettent de prendre un peu de recul par rapport à cette AC et de compléter avec de nouvelles connaissances.

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.

rings

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.

La paravirtualisation

Antoine 7 commentaires

tech-presentation-2Je vais continuer et finir la série d’articles présentant les différents types de virtualisation. J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation et de parler de la virtualisation totale ainsi que de la virtualisation matérielle assistée. Je vais continuer en vous parlant de paravirtualisation. J’ai déjà eu l’occasion d’évoquer la notion de paravirtualisation dans la présentation de Xen que j’avais faite il y a quelques temps.

L’idée de base des précédents types de virtualisation était de faire croire au système d’exploitation qu’il s’exécutait sur une machine physique alors que ce n’était pas le cas. Cette technique est la technique la plus évidente lorsqu’on essaye de virtualiser des systèmes d’exploitation principalement propriétaires ce qui est le cas de VMWare par exemple. Il s’agit d’une méthode qui permet de centraliser toutes les fonctionnalités de virtualisation dans un seul endroit, à savoir la couche de virtualisation. L’inconvénient de cette méthode est que la couche de virtualisation devient rapidement très lourde avec la quantité croissante du nombre de fonctionnalités à implémenter.

La paravirtualisation adopte une vision radicalement différente. Au lieu de chercher à faire croire aux systèmes d’exploitation qu’ils s’exécutent sur une machine physique, il est possible d’adapter le système d’exploitation à la couche de virtualisation. Ceci n’aurait bien évidemment pas été possible sans la présence de logiciels libres…

virtus

La paravirtualisation vise donc à modifier les systèmes d’exploitation pour communiquer avec un hyperviseur au lieu de communiquer avec une machine physique. Sur ce blog, je parlerais d’hyperviseur au sens de Xen ou d’Hyper-V. VMWare parle d’hyperviseur à tord et à travers mais il ne s’agit pas, selon moi, d’un vrai hyperviseur. En réalité, il s’agit d’un système d’exploitation hôte déguisé.

L’hyperviseur au sens de la paravirtualisation est en contact direct avec le matériel physique. Il est l’intermédiaire exclusif entre le matériel et les systèmes d’exploitation. Lorsqu’on se trouve donc dans un système de paravirtualisation, il n’y a plus de notion de système d’exploitation invité et de système d’exploitation hôte. Tous les systèmes d’exploitation sont virtualisés dans le sens où ils disposent d’un noyau adaptés à la couche de virtualisation. Tous les systèmes d’exploitation ne seront pas égaux pour autant, il est possible de donner des accès spécifiques à différents systèmes d’exploitation.

Les systèmes d’exploitation communiquent avec l’hyperviseur via des API de communication. Ces API de communication remplacent les traditionnels appels systèmes. Chaque couche de virtualisation dispose donc de sa propre API. Pour adapter un système d’exploitation à un hyperviseur, il faut donc intégrer son API au noyau. Cela explique en partie le passage en GPL des pilotes Hyper-V de Microsoft.

Au final, la paravirtualisation est une technique particulièrement innovante qui présente une approche plus efficace de la virtualisation. Les avantages de cette technique sont une perte de performance largement réduite par rapport à une virtualisation totale. L’inconvénient majeur est qu’il est nécessaire d’adapter les systèmes d’exploitation pour chaque couche de virtualisation. Afin de résoudre ce problème, il est possible de coupler paravirtualisation et virtualisation matérielle assistée comme dans Xen.

La véritable intégration de la virtualisation dans le réseau

Antoine 1 commentaire

tech-presentation-2J’ai déjà eu l’occasion de parler à travers différents articles de virtualisation de systèmes d’exploitation. Je vais bien entendu continuer cette série d’articles afin de faire le tour de tous les types majeurs de virtualisation cependant je souhaiterais faire une petite parenthèse. Cet article fait suite à une démonstration technologique à laquelle j’ai pu assister dans le cadre de mon stage.

La virtualisation est une technique qui met à mal les configurations et la conception traditionnelle du réseau. Traditionnellement, derrière un port d’un équipement réseau se trouve une machine. Sur cette machine on retrouve une adresse mac et un adresse IP. La virtualisation chamboule cette convention. On se retrouve rapidement à avoir un nombre important de d’adresses mac et d’adresses IP derrière un même port physique. De plus, traditionnellement un port sur lequel on branche une machine est un port en mode « access » en langage Cisco (non propagation des étiquettes de VLAN) alors qu’avec la virtualisation ces ports vont devoir se trouver en mode « trunk » (propagation des étiquettes de VLAN).

Les choses se compliquent de manière significative dès qu’on commence à insérer la notion de migration de machines virtuelles. Traditionnellement, un déplacement de machine nécessite le déplacement d’un technicien et la reconfiguration des équipements. Avec la virtualisation, la migration de machines virtuelles se fait en deux clics à distance et ne doit pas nécessiter l’intervention d’une personne sur site. Ce qui change fondamentalement, c’est qu’on va devoir adapter la configuration du réseau à la volée en fonction de changements applicatifs.

Le réseau est habitué à s’adapter à des changements au niveau 3 du modèle OSI avec les nombreux protocoles et algorithmes de routage. Le réseau est capable de s’adapter tant bien que mal aux changements de topologie de niveau 2 avec des technologies telles que le Spanning Tree. Cependant, il n’a pas du tout l’habitude de s’adapter à des changements applicatifs. Or dans le cas de la migration de machines virtuelles, il va falloir qu’il le fasse et qu’il le fasse vite et bien.

La virtualisation va donc s’interfacer avec le réseau pour pouvoir le commander et le faire s’adapter en fonction des migrations de machines virtuelles. L’interfaçage avec une interface de configuration du réseau sera donc indispensable. La mise en place d’un équipement réseau (virtuel ou physique peu importe) pour coordonner ces modifications et modifier les topologies va également être nécessaire.

En termes de fonctionnalités, chaque machine virtuelle va avoir son propre port virtuelle sur lequel il sera possible d’associer des configurations qui s’attribuent traditionnellement aux ports de switchs ou de routeur. L’équipement réseau virtuel pourra être capable de servir de routeur, d’IDS ou même de firewall applicatif. La gestion du réseau sera centralisé car il est indispensable de pouvoir gérer tous les équipements réseau d’un seul emplacement afin d’avoir une harmonie.

Vous allez me dire que tout ceci est bien beau et bien sympa, et vous aurez bien raison. Cependant sans implémentation pratique cela ne servirait pas à grand chose. Il n’existe, hélas, aucune implémentation libre de ce type d’application mais il en existe cependant des implémentations propriétaires. J’ai nommé Cisco Nexus 1000v mais qui n’est disponible que pour VMWare. Selon certaines informations, Citrix serait également en train de travailler sur une implémentation open source d’un telle application ce qui serait une avancée majeure pour la virtualisation open source ! De plus, la plateforme Cisco Nexus 1000v semble être prévue pour être exécutée sur plusieurs hyperviseurs étant donné qu’il est possible de spécifier le type d’hyperviseur. Aujourd’hui, seul VMWare fonctionne mais pourquoi pas Xen demain ?

Ca, c’est le futur de la virtualisation ! Et ca fait plaisir !

La virtualisation matériel assistée

Antoine 2 commentaires

tech-presentation-2Je vais continuer dans la suite logique des billets précédents. Pour rappel, j’ai précédemment parlé de l’intérêt de la virtualisation, proposé une classification des différents types de virtualisation et puis expliqué plus en détail la virtualisation totale. Je vais donc continuer cette série d’article en vous parlant de virtualisation matériel assistée.

Tout d’abord, le terme de virtualisation matériel assistée semble assez explicite. On comprend bien qu’il s’agit de virtualisation qui va être assistée par une fonctionnalité spécifique du matériel. Les détails du fonctionnement de cette technologie le sont cependant bien moins. Ce terme est une traduction de l’anglais « Hardware Assisted Virtualization ». On peut aussi trouver comme autre traduction « virtualisation assistée par matériel ». Tous ces termes sont cependant équivalents. Cependant, la virtualisation partielle n’a aucun rapport.

HAV

Comme vous pouvez le voir, le schéma d’architecture ne change que très peu par rapport à la virtualisation totale. Avec la virtualisation totale, nous parlions de couche logicielle de virtualisation alors que parlerons plutôt de « Virtual Machine Monitor » ou VMM dans le cas de la virtualisation matériel assistée.

Une extension du jeu d’instructions du processeur

Ensuite, il est important de préciser que la virtualisation matériel assistée n’est pas une technique à part entière. Il s’agit en réalité d’une extension du principe de virtualisation totale. La principale modification qui est apportée est l’ajout d’extensions processeur de virtualisation. Vous en avez surement entendu parlé, je parle bien d’Intel VT et d’AMD-V. Ces instructions ont été implémentées dans les processeurs afin de pouvoir améliorer la virtualisation totale. Ces instructions sont une extension du jeu d’instructions exécutables par le processeur similairement à SSE ou MMX.

Ces instructions apportent plusieurs améliorations. Tout d’abord, elles créent un anneau -1 qui sera l’endroit privilégié de l’exécution d’un hyperviseur. Ceci permet de garder la localisation traditionnelle des anneaux avec le système d’exploitation présent dans l’anneau 0 et les applications dans l’anneau 3. Les autres ne sont jamais utilisé à l’exception de quelques rares cas. J’aurais l’occasion de revenir plus tard sur la notion d’anneau. Le placement du système d’exploitation dans son anneau traditionnel permet de simplifier l’accès à certains instructions et donc de supprimer une partie du travail de la couche de virtualisation.

De plus, elles permettent aux machines virtuelles de gérer leurs propres interruptions et donc changements de contexte. Ceci évite à la couche logicielle de virtualisation de devoir les gérer. Egalement, elles permettent au matériel de gérer directement  les zones de mémoire vive (non forcément linéaires) disponibles au machines virtuelles. Sans les extensions, il était nécessaire que la couche de virtualisation émule et gère des zones.

Si vous souhaitez plus d’informations sur ces instructions, je vous invite à consulter la documentation d’Intel disponible ici ou ici.

Au final, les extensions processeur de virtualisation permettent d’améliorer la technique de la virtualisation totale. Ceci se fait par l’ajout d’un degré d’intelligence au niveau du matériel qui sera conscient de l’utilisation d’une couche de virtualisation. La virtualisation matériel assistée est donc une évolution du principe de virtualisation totale.

Les différents types de virtualisation : La virtualisation totale

Antoine 1 commentaire

Dans l’article précédent, j’ai proposé une classification des différents types de virtualisation de systèmes d’exploitation basée sur différents critères. Je vais continuer cette série d’articles en vous présentant la virtualisation totale qui est le type de virtualisation le plus répandu historiquement.

La virtualisation totale consiste à émuler l’intégrité d’une machine physique. Pour rappel, l’émulation est le principe qui consiste à remplacer un composant matériel par une application dont le comportement est similaire voire identique. Le cas le plus classique d’émulation est l’émulation de vieilles consoles de jeux telles que la Super Nintendo ou la Game Boy. L’objectif de la virtualisation totale est donc de faire croire au système d’exploitation invité qu’il est présent sur du matériel physique et non au dessus d’une couche applicative.

Il s’agit de l’approche la plus basique en terme de virtualisation : « On ne peut pas avoir du matériel physique du coup on va le remplacer par une application ». Il s’agit de la première approche qui a été adoptée par VMWare en 1999 lors de sa création.

Virtualisation Totale

Comme présenté dans le schéma, la base installée sur le matériel est un système d’exploitation classique. Tous les systèmes d’exploitation, à ma connaissance, sont capables d’exécuter une application de virtualisation totale. Ceci est lié à la simplicité de son fonctionnement. La « Couche Logicielle » évoquée dans le schéma est une application telle que VMWare ou VirtualBox qui s’exécute comme toute autre application. Cette couche logicielle va ensuite émuler autant de matériel qu’il y a de machines virtuelles.

Certains vendeurs telles que VMWare vendent des solutions de virtualisation nommées « Bare Metal Hypervisor ». Cependant ce que VMWare appelle hyperviseur n’est absolument pas un hyperviseur au sens de Xen. Il s’agit en réalité d’un Linux Red Hat customisé.

L’inconvénient de la virtualisation totale est la performance. Il est nécessaire d’émuler de nombreux composants physiques et de capter toutes les instructions émanants des machines virtuelles ce qui consomme beaucoup de ressources. Des tests montrent de pertes de performance de l’ordre de 20% à 80%. Il est possible d’améliorer significativement les performances en ajoutant des pilotes de paravirtualisation qui permettent un meilleur interfacage avec la couche logicielle sous-jacente.