Cryptoprocesseurs et virtualisation

Transcription

1 Cryptoprocesseurs et virtualisation Étude bibliographique Master Recherche en Informatique 2 1 er février 2007 Auteur : Cyril Brulebois <cyril.brulebois@enst-bretagne.fr> Encadrants : Guillaume Duc et Ronan Keryell Laboratoire Informatique & Télécommunications Département Informatique École Nationale Supérieure des Télécommunications de Bretagne

2 Table des matières Introduction 3 1 Première partie : cryptoprocesseurs L approche AEGIS L approche XOM Protection du bus d adresses : HIDE CryptoPage Seconde partie : émulation et virtualisation QEMU Xen VMware Conclusion 11 Références 12 2

3 Introduction Avec le développement des communications à haut débit et l augmentation des capacités de stockage de masse, plusieurs problématiques ont émergé. D une part on veut pouvoir garantir une gestion de droits numériques (communément appelés «DRM»), qu il s agisse de contenus (notamment audio et vidéo) ou de licences logicielles, malgré les facilités de communication et de transfert d informations actuelles. D autre part, il est convient d assurer la sécurité des systèmes informatiques, qu il s agisse des machines de particuliers ou de systèmes sensibles (tels que les banques, les systèmes confidentiels défense), y compris contre les attaques physiques. Enfin, un nombre toujours croissant de systèmes de calcul distribué est utilisé, tels que SETI@home et distributed.net, pour résoudre des problèmes difficiles. Or il peut être crucial de garantir que les résultats obtenus n ont pas été truqués ou altérés, c est pourquoi il est nécessaire de disposer de mécanismes garantissant la confidentialité, l intégrité et l authenticité des messages échangés, y compris avec des machines dont on n est pas propriétaire. Différents systèmes, appartenant au monde des cryptoprocesseurs, ont été proposés et seront étudiés dans une première partie. Dans la seconde, différents systèmes d émulation et de virtualisation seront présentés, ainsi que les problématiques de performances associées. 3

4 1 Première partie : cryptoprocesseurs 1.1 L approche AEGIS Le but d AEGIS [1] est d assurer à la fois la sécurité contre les attaques physiques et logicielles. Seul le processeur est considéré comme étant de confiance, à la différence de tout ce qui lui est extérieur, comme la mémoire. On distingue ici entre deux caratéristiques : d une part la possibilité de détecter la moindre modification illicite de la mémoire, afin de garantir l intégrité, et d autre part la possibilité de basculer dans un environnement garantissant même la confidentialité. Deux approches sont présentées : l une suppose qu on dispose d un noyau de confiance, l autre suppose que l on n a pas de tel noyau à disposition. La garantie de l intégrité nécessite de s assurer que la mémoire est correcte, dans le sens où la valeur lue depuis une adresse particulière de la mémoire doit correspondre à la dernière valeur stockée par le processeur à cette adresse. En plus de la vérification de l intégrité de la mémoire, il est nécessaire de la chiffrer si l on veut obtenir un environnement garantissant la confidentialité. La bonne exécution est rendue possible via deux instructions permettant respectivement d entrer et de sortir du mode protégé : enter aegis et exit aegis, tandis que l instruction sign msg permet d exporter les résultats en générant une signature avec la clé privée du processeur (faisant partie d un couple clé publique-clé privée). En plus du message à transmettre, le hash du programme exécuté est lui aussi incorporé dans la signature à calculer, on peut ainsi distribuer des traitements aisément et s assurer que tel résultat a été calculé sur telle machine (signature via la clé privée du processeur) avec tel programme (vérification du hash). L extension de cet environnement garantissant l intégrité à un environnement garantissant de plus la confidentialité s effectue par l ajout d une nouvelle instruction, set aegis mode, permettant d activer ou de désactiver ce mode confidentiel. Quand il est activé, deux méthodes de chiffrement sont utilisées : le chiffrement asymétrique est utilisé pour déchiffrer le flot d instructions et de données contenus dans le programme chiffré (avec la clé privée du processeur), le chiffrement symétrique est utilisé pour chiffrer les données générées pendant l exécution du programme. Malheureusement, cet article évoque la possibilité d attaque de la mémoire, même chiffrée, par motifs mais ne traite pas ce problème, les programmes étant supposés «être bien écrits» et ne pas contenir de telles fuites potentielles. Du point de vue des performances, on constate que l on doit se concentrer sur les instructions appelées les plus fréquemment, à savoir la protection des registres et la gestion du cache interne au processeur, pour lesquels le surplus de calcul («overhead») est négligeable, ainsi que la vérification d intégrité de la mémoire hors-processeur, qui est nettement plus coûteuse. 4

5 Afin de conserver des performances convenables, des arbres de Merkle [2] sont utilisés pour vérifier l intégrité de données dynamiques stockées dans un site n étant pas de confiance (e.g. la mémoire vive). Fig. 1 Arbre de Merkle Sur la figure 1, un arbre réduit est représenté, les feuilles représentant les données et chaque nœud représentant la concaténation des hashes des deux nœuds fils. Ainsi il n est pas nécessaire de recalculer le hash de tout l espace mémoire à chaque vérification, il suffit de recalculer au plus un nombre de hashes égal à la hauteur de l arbre. On passe alors d un algorithme en O(n) à un algorithme en O( n), ce qui est un gain considérable. 1.2 L approche XOM Les architectes de XOM (execute-only Memory) [3] considèrent qu aucun mécanisme purement logiciel n est suffisant pour garantir la confidentialité du code et proposent le mécanisme suivant : en stockant le code sous forme chiffrée, il est possible de n autoriser que le processeur à y accéder, afin que celui-ci effectue les différentes instructions sans qu aucun des utilisateurs de la machine n y ait accès. On retrouve la même approche que celle d AEGIS. Afin de protéger les applications chiffrées les unes des autres, XOM utilise des compartiments auxquels correspondent des clés de session. Bien entendu, les applications non chiffrées peuvent continuer à fonctionner normalement, dans un compartiment non protégé. XOM insiste particulièrement sur ce cloisonnement des différentes applications et on notera la présence d un hyperviseur ou moniteur de machines virtuelles, les différentes applications étant étiquetées par un identifiant XOM, et ne pouvant interagir les unes avec les autres que si elles partagent la même étiquette, afin de garantir la sécurité de chacune. La protection est assurée par une combinaison de cryptographie à clé publique et à clé symétrique. La cryptographie à clé publique permet un chiffrement fort mais a de lourdes conséquences sur les performances, c est pourquoi elle n est utilisée que sur le préambule de chaque application XOM. Il suffit en effet de stocker la partie privée d un couple clé publique-clé privée dans un processeur XOM, ce qui garantit que seul le processeur cible (avec la clé duquel on a chiffré le code) peut faire tourner cette application, tout en protégeant la clé symétrique qui sera utilisée pour déchiffrer le reste du code. Ainsi on peut s attendre à conserver des performances acceptables, en tout cas meilleures que celles que l on peut obtenir avec AEGIS puisque le chiffre- 5

6 ment asymétrique n intervient qu une seule fois à l initialisation, le chiffrement symétrique étant utilisé ensuite à la fois pour les données manipulées par le programme et pour le déchiffrement du programme lui-même. Cependant, le coût d accès à la mémoire est relativement important, à cause du mécanisme de contrôle d accès mis en place et la latence mémoire est relativement impactée, ce qui peut restreindre le champ d application de XOM. 1.3 Protection du bus d adresses : HIDE Après l introduction de XOM, des critiques se sont élevées à son encontre, car ce mécanisme n aborde pas le problème de la fuite d informations sur le bus d adresses. Ce problème est pourtant largement reconnu, comme le prouvent la conception et la production des puces à bus protégé telles que DS5000FP [4] et DS5002FP [5] par Dallas Semiconductors, à utilisation commerciale (e.g. carte de crédit). Ce problème est évoqué dans [1] et [3], mais est respectivement ignoré, comme indiqué précédemment, et considéré comme problème à régler. Bien que les instructions soient chiffrées et uniquement accessibles par le processeur cible, le flot de contrôle est exposé. En effet, en particulier dans une boucle, des adresses contiguës sont accédées et il devient ainsi possible d obtenir des informations sur le déroulement du programme. Dans [6] est montré qu une telle détection de boucles peut se transformer en un point de départ pour une attaque par rejeu. HIDE (Hardware-support for leakage-immune Dynamic Execution) [7] se base sur le modèle XOM, où seul le processeur est supposé digne de confiance. XOM est par défaut sensible aux attaques basées sur la réutilisation de code. En effet, celle-ci représente une part importante de code, en particulier via l utilisation de bibliothèques courantes (e.g. de compression). Or espionner le bus d adresses permet d identifier aisément les algorithmes utilisés. De plus, les branchements conditionnels permettent de récupérer des informations critiques. En effet, les algorithmes étant connus (l exemple donné dans l article est un extrait de code utilisé dans les algorithmes Diffie-Hellman et RSA : l exponentielle modulaire), il est possible d obtenir une succession de renseignements sur les valeurs comparées, permettant ainsi de remonter jusqu à des données critiques (e.g. la clé secrète). L analyse et la réfutation des arguments que l on pourrait objecter à la pertinence de l espionnage du bus d adresses semblent particulièrement complètes et valables, en particulier en ce qui concerne les mécanismes de cache. On pourrait en effet avancer que peu d adresses risquent d être exposées grâce aux caches. Cependant, en environnement multiutilisateur et multitâche, le cache risque d être vidé à tout moment, en particulier si le système d exploitation n est pas digne de confiance. La solution proposée par HIDE se compose d une microarchitecture et d un compilateur, dont le but est de rompre la corrélation entre les adresses mémoire répétées, en les permutant à des moments bien choisis. Outre l approche naïve consistant à parcourir en boucle toute la mémoire, l article présente une méthode introduite par [8] : construire une séquence d adresses correspondant à une distribution de probabilités donnée. Ainsi les adresses espionnées apparaîtront comme des variables aléatoires obéissant à une distribution donnée mais ne laisseront 6

7 filtrer aucune information quant aux adresses réellement utilisées par le processeur. Cependant, il est nécessaire de stocker les adresses initiales afin de pouvoir permuter l espace d adresses quand une adresse initiale est à nouveau utilisée. Puisque ce tampon («shelter buffer») doit être parcouru à chaque accès mémoire pour savoir si une adresse a été accédée, et parcouru en entier (pour ne pas laisser savoir à un attaquant si une valeur a été trouvée et, le cas échéant, laquelle), on pourrait être tenté de le stocker au niveau du processeur («onchip») au lieu de le stocker en mémoire vive. Une autre approche est proposée, dite «hide cache», consistant à placer la protection du bus d adresses audessus d un cache normal, afin de garantir une empreinte mémoire faible et des performances peu impactées. L idée est de verrouiller les blocs concernés, entre deux permutations. En ajoutant à cela une prépermutation, on évite certains problèmes : le remplacement possible d un bloc verrouillé quand il a été inutilisé pendant le plus grand laps de temps ainsi que la possibilité que tous les blocs soient verrouillés, ce qui pourrait entraîner des blocages. Afin de permettre de protéger de grandes parties de la mémoire, les permutations peuvent se dérouler au niveau d un «chunk» (que l on traduira par «bloc» par la suite) défini comme un groupe d une ou plusieurs pages protégées et permutées ensemble. Les transitions peuvent ainsi avoir lieu à l intérieur d un même bloc (transition «intrabloc») ou entre plusieurs (transition «interbloc»). D après les tests effectués, près des trois quarts des transitions ont lieu à l intérieur d un bloc, même avec la plus petite taille possible, i.e. une page. En plus d être efficace, la protection à ce niveau est flexible puisque l on peut choisir de découper la mémoire en blocs de taille différente. Enfin, comme l unité de base est la page, l implémentation est facilitée, les pages étant supportées par le matériel comme par le système d exploitation. Des optimisations au niveau de la compilation sont de plus possibles pour réduire encore le nombre de transitions interblocs, par exemple en rapprochant des fonctions s appelant les unes les autres, ou encore en jouant sur la disposition des données statiques. Les résultats annoncés semblent excellents puisqu on arrive à plus de 85 % de séquences protégées et plus de 95 % de code et de données statiques cachés. 1.4 CryptoPage Dans [9], il est aussi fait référence aux microprocesseurs Dallas Semiconductors DS5000FP [4] et DS5002FP [5] et le principe de fonctionnement est détaillé : d une manière semblable à ce que l on a vu précédemment, il s agit d ajouter un mécanisme de chiffrement entre le microcontrôleur et la mémoire, l ensemble constitué du microcontrôleur et du mécanisme de chiffrement étant alors appelé cryptoprocesseur. Afin d éviter les attaques à texte connu (e.g. un vecteur rempli de zéros après initialisation), le chiffrement fait intervenir l adresse. On retrouve donc un système en quelque sorte similaire à celui de HIDE où la compréhension de l allocation mémoire se retrouve compliquée. Un bruit est même généré (fausses lectures de la mémoire) lorsqu il y a peu d accès mémoire, afin de rendre la tâche de l attaquant plus difficile. Enfin une protection physique est présente pour empêcher toute reprogrammation ou ouverture du boîtier : il y a surveillance 7

8 de la tension d alimentation et même autodestruction en cas d ouverture du boîtier. Dans la version «sécurisée» du microcontrôleur, le DS5002FP, ont été ajoutés d autres mécanismes de protection ainsi qu un générateur aléatoire plus solide (64 bits au lieu de 40) permettant de tirer une clé au hasard. On pourrait s attendre à une sécurité accrue, cependant il y a deux écueils : d une part la fonction de chiffrement est bijective ; d autre part, le faible nombre d instructions possibles sur un microcontrôleur rend aisée une attaque par force brute, puisqu il suffit de tester toutes les instructions possibles (soit 256 puisqu on est sur 8 bits) espacées par une remise à zéro afin de garantir un état initial cohérent à chaque essai. Il est alors possible de faire sortir progressivement de l information. Une protection possible contre ce genre d attaques est celle considérée dans le cas des mahines de Robert M. Best [10], i.e. une destruction pure et simple lorsqu une instruction non définie est rencontrée. Cette approche est malheureusement limitée par le fait qu il peut y avoir d autres motifs qu une attaque à une instruction erronée, par exemple un bogue ou une erreur de conception dans un programme. Afin d éviter ce genre d approches destructives et coûteuses, et toujours dans le but d empêcher une recherche par force brute, on peut plutôt considérer de chiffrer plus de données en une seule fois ou bien d ajouter une signature. Cette dernière approche est celle considérée dans CryptoPage et un hash est utilisé pour vérifier la validité des données déchiffrées. En considérant un hash de longueur 128 bits, on arrive à une augmentation d occupation mémoire de l ordre de 50 %, pour moins d une chance sur d arriver à injecter une donnée passant la vérification, ce qui garantit une certaine robustesse. Là encore la signature est assurée par des arbres de Merkle [2], comme dans AEGIS, comme détaillé précédemment ainsi que dans [11]. Une nouvelle alternative se présente alors : soit l on manipule à la fois des données en clair et des données chiffrées en mémoire, soit l on sort l adresse physique de l adresse virtuelle à la place de l adresse physique «normale», auquel cas la traduction peut être intégrée directement à l unité de gestion de mémoire («MMU»). Cette dernière approche est préférée car il suffit de raisonner en adresse virtuelle, gérée au niveau du système d exploitation. On peut insérer des redondances à différents niveaux afin d augmenter la résistance à diverses attaques : par exemple toujours appliquer deux fois de suite le chiffrement, afin de vérifier qu on obtient bien la même valeur et éviter les incohérences qui pourraient résulter d une attaque. De même, on peut stocker la clé privée à différents emplacements pour limiter les risques de modification ou au moins les détecter. D un point de vue performances, le choix déterminant se situe au niveau de l algorithme de chiffrement symétrique utilisé pour le chiffrement et le déchiffrement des données entre les caches et la mémoire. Heureusement, il est possible de répliquer l algorithme choisi, CS-Cipher [12], afin de paralléliser l accès en lecture à des données au sein d une même ligne, réduisant alors la latence et permettant d atteindre un débit suffisant. 8

9 2 Seconde partie : émulation et virtualisation 2.1 QEMU QEMU [13] est un émulateur sous licence libre, au même titre que Bochs [14], ayant but de faire tourner sans modification une machine cible sur une machine hôte, non nécessairement semblable, par exemple un système Windows sur un système Linux, ou inversement. Les possibilités de débogage sont particulièrement intéressantes puisqu à tout moment, on peut stopper la machine virtuelle pour l examiner. Contrairement à Bochs, QEMU permet d émuler différentes architectures, au lieu du seul Intel x86, parmi lesquelles ARM et PowerPC (tant en processeur cible, en émulation utilisateur ou système, qu en processeur hôte). Afin de limiter le coût de la traduction des instructions du processeur cible vers le processeur hôte, le code binaire obtenu est mis en cache, on s éloigne donc en ce sens d un simple interpréteur. La première étape dans cette traduction est de découper (à la main) chaque instruction processeur en opérations miniatures («micro ops»), chacune étant implémentée dans un minuscule fichier source C, compilé par GCC en un fichier objet. En choisissant un nombre limité d opérations miniatures (e.g. quelques centaines) et en les combinant, on arrive à reproduire chacune des instructions du processeur cible. Cette combinaison est faite à la volée par un générateur de code dynamique, dyngen. L essentiel du travail est fourni lors de la phase de découpage et d implémentation de ces opérations miniatures, que l on cherche à optimiser au maximum. Un point intéressant est le fait qu une unité de gestion de mémoire («MMU») logicielle est supportée afin de permettre à plusieurs systèmes d exploitation de tourner simultanément. La traduction d adresses virtuelles en adresses physiques est alors effectuée à chaque accès mémoire, ce qui a un impact non négligeable sur les performances, malgré l utilisation d un cache. C est d ailleurs un des grands chantiers évoqués en conclusion de l article. On notera toutefois qu un module d accélération est disponible, sous forme de module pour le noyau Linux, bien qu il ne soit pas (encore) sous licence libre, l auteur espérant trouver un sponsor ou un partenaire avant de changer sa licence. Un autre mode intéressant est l émulation du mode utilisateur, ce qui rappelle des mécanismes comme User-mode Linux [15]. Au niveau du processeur il s agit juste d un sous-ensemble de l émulation d un système complet. De plus, la simulation de l unité de gestion de la mémoire n est pas nécessaire puisque l affectation mémoire du système utilisateur (invité) est gérée directement par le système hôte. Des mécanismes de gestion des problèmes de boutisme («endianness»), de même que les conversions 32/64 bits, sont intégrés directement dans QEMU, sous forme d appel système Linux. Enfin, pour être porté sur de nouvelles architectures, QEMU nécessite entre autres choses que dyngen soit porté, processus dont la difficulté est évaluée à celle du portage d un éditeur de liens dynamique. 2.2 Xen Xen [16] est présenté comme un moniteur de machines virtuelles permettant à une multitude de systèmes d exploitation de cohabiter sur une même machine 9

10 physique, en partageant les mêmes ressources. Il s agit ici de permettre de rentabiliser l achat d une machine actuelle, disposant de suffisamment de ressources pour que celles-ci soient partagées entre plusieurs machines virtuelles, permettant ainsi le cloisonnement et limitant ainsi les dégâts causés par une attaque. En effet, si une machine virtuelle est compromise, les autres ne sont pas affectées directement et un rebond est alors nécessaire à l attaquant avant d accéder à de nouveaux services et à de nouvelles informations. Afin de fixer les idées, les concepteurs visent à héberger jusqu à 100 machines virtuelles sur un unique serveur, grâce aux très bonnes performances de Xen. En fait il ne s agit pas exactement de virtualisation mais de paravirtualisation, puisqu il s agit de porter (il est vrai avec de très légères modifications en général) le système voulu vers une abstraction de machine virtuelle idéale. A contrario, la virtualisation (parfois appelée virtualisation complète) ne nécessite pas cette étape de portage. Une fois le système porté, les pertes en performance («overhead») sont négligeables, de l ordre de quelques pourcents seulement, ce qui montre à quel point le système est performant et à quel point l objectif fixé semble réaliste. 2.3 VMware À la différence de Xen, VMware propose la virtualisation complète, permettant ainsi la transition de systèmes existant vers des environnements virtualisés sans la moindre modification. Pour cela, VMware utilise une combinaison d exécution directe et de techniques de traduction binaire (cette dernière partie étant évitée dans la paravirtualisation, grâce au portage vers la machine virtuelle idéale). La limite de l approche de Xen est que tous les systèmes ne sont pas à source ouvert, il n est donc pas possible de tous les porter vers l architecture Xen. Le test de performances effectué semble montrer que la virtualisation complète permet d obtenir de bien meilleures performances que la paravirtualisation dans le cas de l arithmétique entière comme dans le cas de l arithmétique à virgule flottante, alors que l utilisation intensive d extensions multimédia, la compression ou le chiffrement donnent des résultats comparables pour Xen et VMware, très proches des performances natives. Au prix d une complexité plus grande que dans le cas de la paravirtualisation, il semble donc possible de gagner sur deux points : les systèmes existant (et dont les sources sont potentiellement non disponibles) peuvent s exécuter sans modification d une part ; et d autre part les performances semblent meilleures. 10

11 Conclusion De multiples systèmes permettant d assurer divers niveaux de protection ont été présentés, qu il s agisse de la détection de modification des données ou de la protection de la confidentialité de celles-ci, à la fois contre des attaques logicielles (processus tournant sur la même machine et tentant d accéder aux données accédées ou au code exécuté) et contre les attaques matérielles (y compris via un espionnage direct du bus d adresses. Il est ainsi possible d exécuter des programmes de manière sûre, même sur des machines dont on n est pas propriétaire (e.g. sur une grille), tout en étant sûr de la validité des résultats renvoyés, ce qui est particulièrement utile pour des problèmes difficiles, rencontrés en particulier en biométrie. De même, plusieurs approches ont été présentées, chacune permettant de faire tourner un système invité sur un système hôte, avec des impacts plus ou moins importants sur les performances. Cependant, il semble qu il n y ait pas encore eu d étude sur l impact des architectures de cryptoprocesseurs sur les systèmes de virtualisation. De même, il semblerait intéressant d étendre ces architectures aux récents processeurs multicœurs. 11

12 Références [1] Suh (G. E.), Clarke (D.), Gassend (B.) et al., «Aegis : Architecture for tamper-evident and tamper-resistant processing», dans Proceedings of the 17th International Conference on Supercomputing ( Ics 03), p , juin [2] Merkle (R. C.), «A certified digital signature», dans Proceedings on Advanced in Cryptology ( Crypto 89), vol. 435, p Springer-Verlag New York, Inc., [3] Lie (D.), Thekkath (C.), Mitchell (M.) et al., «Architectural support for copy and tamper resistant software», dans Proceedings of the Ninth International Conference on Architectural Support for Programming Languages and Operating Systems ( Asplos IX), p , octobre [4] Dallas Semiconductors. «DS5000FP Soft Microprocessor Chip», novembre [5] Dallas Semiconductors. «DS5002FP Secure Microprocessor Chip», novembre pdf. [6] Gassend (B.), Suh (G. E.), Clarke (D.) et al., «Caches and hash trees for efficient memory integrity verification», dans Proceedings of the 9th International Symposium on High-Performance Computer Architecture ( Hpca 03), p , février [7] Zhuang (X.), Zhang (T.) et Pande (S.), «Hide : an infrastructure for efficiently protecting information leakage on the address bus», dans Proceedings of the 11th International Conference on Architectural Support for Programming Languages and Operating Systems ( Asplos-XI), p Acm Press, octobre [8] Goldreich (O.) et Ostrovsky (R.), «Software protection and simulation on oblivious rams», Journal of the ACM, vol. 43, n o 3, 1996, p [9] Keryell (R.), «CryptoPage-1 : vers la fin du piratage informatique?», dans Symposium d Architecture ( SympA 6), p , Besançon, juin [10] Best (R. M.), «Preventing software piracy with crypto-microprocessors», dans IEEE Spring COMPCON 80, p IEEE Computer Society, février [11] Lauradoux (C.) et Keryell (R.), «CryptoPage-2 : un processeur sécurisé contre le rejeu», dans Symposium en Architecture et Adéquation Algorithme Architecture ( SympAAA 2003), p , La Colle sur Loup, France, octobre [12] Stern (J.) et Vaudenay (S.), «Cs-cipher», dans Vaudenay (S.), éditeur, Fast Software Encryption : 5th International Workshop, vol (coll. Lecture Notes in Computer Science), p , Paris, France, mars Springer-Verlag. [13] Bellard (F.), «QEMU, a fast and portable dynamic translator», dans Proceedings of the USENIX 2005 Annual Technical Conference, FREENIX Track, p , avril [14] «Bochs : The open source ia-32 emulation project», novembre

13 [15] Dike (J.), «User-mode linux», dans Proceedings of the 5th Annual Linux Showcase & Conference, p. 3 14, novembre [16] Barham (P.), Dragovic (B.), Fraser (K.) et al., «Xen and the Art of Virtualization», dans Proceedings of the Nineteenth ACM symposium on Operating systems principles, p , octobre