Soutenance mémoire
Virtualisation et machines virtuelles
La définition qui fait le plus souvent référence concernant la notion de machine virtuelle est celle de Gerald J. Popek et coll. dans [2].
Definition 1.1. Une machine virtuelle est une copie d’une machine physique qui doit demeurer performante et isolée. Une machine virtuelle s’exécute sous le contrôle exclusif du gestionnaire de machines virtuelles qui va mettre en place un environnement d’exécution proche de la machine physique et qui n’engendre pas de perte significative de performance.
Pour mettre en œuvre cette définition, il existe plusieurs types et techniques de virtualisation dont nous détaillons ici les principaux.
Types de virtualisation
Le concept théorique de machine virtuelle est mis en pratique grâce à la virtualisation. En informatique, la virtualisation désigne l’abstraction des ressources d’une machine physique, et ce à différents niveaux. Il existe deux types de virtualisation qui sont définis par le comportement du logiciel exécuté et virtualisé. Le premier cas considère que les logiciels sont conscients d’être virtualisés. Dans ce cadre, ils interagissent explicitement avec le gestionnaire de machines virtuelles sous-jacent (sur lequel nous reviendrons dans la suite) afin de demander l’exécution d’actions spécifiées, nécessitant par exemple des privilèges plus élevés. On parle dans ce cas de paravirtualisation. Un logiciel développé pour un environnement non virtuel doit donc être adapté pour pouvoir s’exécuter correctement dans ce type d’environnement.
Par opposition, la virtualisation complète ou full virtualization prend en charge des logiciels qui n’ont aucunement conscience d’être virtualisés. Ceux-ci interagissent avec les interfaces logicielles et matérielles qu’ils utilisent habituellement hors contexte de virtualisation. Il incombe donc au gestionnaire de machines virtuelles de mettre en place les interfaces logicielles ou d’émuler le matériel rendant possible cette exécution. Ce type de virtualisation permet donc d’exécuter directement un logiciel développé hors contexte de virtualisation sans lui appliquer de modification.
Techniques de virtualisation
Pour mettre en œuvre la virtualisation, il existe différentes techniques, abstrayant différentes ressources matérielles et logicielles : les périphériques ; l’interface logicielle d’un système d’exploitation et d’un logiciel ; certaines parties du processeur ; le processeur dans son intégralité et enfin une architecture matérielle entière. Ces techniques sont valables dans les architectures virtualisables selon la définition de Popek et ses associés [2], dans lesquelles l’exécution d’un logiciel peut être contrôlée par une entité plus privilégiée, le gestionnaire de machines virtuelles. Ce contrôle est exercé en interceptant l’exécution d’instructions privilégiées pour donner la main au gestionnaire de machines virtuelles . Sans ces interceptions, non seulement le gestionnaire de machines virtuelles ne peut plus gérer les ressources entre les différentes machines virtuelles, mais en plus, une de ces machines peut alors exécuter des instructions qui auraient pour effet de désinstaller complètement le gestionnaire de machines virtuelles.
Virtualisation de la mémoire Dans les processeurs actuels, les applications possèdent un espace d’adressage virtuel qui est traduit et filtré selon une configuration mise en place par le noyau du système d’exploitation. Cela permet à l’application d’imposer la cartographie de son espace mémoire au chargeur d’application, qui lui met en place la traduction d’adresse demandée. Cela apporte aussi certaines garanties de sécurité, en rendant inaccessible l’espace mémoire d’applications s’exécutant dans un contexte différent. on comprend que les processeurs 1 et 2 ont la même structure et peuvent contenir certaines adresses virtuelles identiques. Par contre dans la mémoire physique, les espaces mémoire alloués par les 2 processeurs sont bien différents. Toutefois, certains segments peuvent être partagés, notamment les bibliothèques partagées, mais aussi certaines mémoires de données affectées à la communication inter processus.
Émulation de processeurs L’émulation de processeurs est un cas spécial de la virtualisation dans le sens où elle reproduit un environnement d’exécution complet en interprétant logiciellement les instructions d’un programme compilé pour une architecture donnée . On parle parfois aussi de binary translation. Il existe plusieurs types d’émulation, en fonction du niveau choisi pour réaliser la translation. En ce qui concerne les applications, certains langages de programmation compilés, tels que Java ou la famille .NET, ciblent des architectures et un jeu d’instructions virtuel pour des raisons de portabilité. L’exécution de ces programmes doit être prise en charge par une machine virtuelle fournie par le développeur du langage, qui émule les instructions du programme. La machine virtuelle, quant à elle, est écrite en code natif pour une plateforme donnée. Ainsi, le développeur d’application n’a pas à supporter différents environnements matériels et systèmes d’exploitation hôtes, ce support étant pris en compte par les différentes machines virtuelles. D’autres émulateurs sont destinés à émuler des systèmes d’exploitation entiers (noyau et applications). Pour ce faire, ils sont amenés à émuler entièrement le comportement du processeur utilisé dans le logiciel. Pour conséquent, il est donc nécessaire de virtualiser également les périphériques (réseau, stockage et affichage). Notons que le code des applications et du noyau font partie des données de l’émulateur.
Émulation du noyau Afin d’améliorer les faibles performances liées à l’émulation, certains concepteurs de gestionnaires de machines virtuelles comme VMware [3] et QEMU associé à KQEMU [4], mêlent l’émulation avec l’exécution réelle de code dans le cadre de la virtualisation d’un système complet. Les applications du système virtualisé, non privilégiées, peuvent être exécutées comme des applications classiques. Le noyau est, quant à lui, entièrement émulé, de façon à contrôler entièrement son comportement . Ce choix se justifie, en ce qui concerne les performances, par le fait que le processeur passe très peu de temps dans l’exécution du noyau par rapport à l’exécution des applications et de ce fait diminue largement l’impact de l’émulation sur les performances du système.
Conteneurs d’applications Le but de ce type de virtualisation est de pouvoir obtenir plusieurs instances d’espaces utilisateurs (applications, systèmes de fichiers, services, configurations, etc.), tout en gardant un seul noyau de système d’exploitation partagé entre les différentes instances virtuelles. On parle aussi de conteneurs ou conteneurs d’application, software containers en anglais [5], [6], [7], [8], [9]. Les interfaces logicielles entre l’application et le noyau du système d’exploitation sont donc instrumentées pour pouvoir mettre en place ce type d’environnement d’exécution d’applications. Notons que les conteneurs rendent possible l’exécution d’applications développées pour un système d’exploitation différent sans leur apporter de modification.
Virtualisation logicielle des périphériques Les bus et périphériques peuvent être aussi virtualisés afin de supporter l’exécution de noyaux de systèmes d’exploitation et de drivers dans un environnement virtuel. Dans ce cas, les interfaces matérielles d’entrées / sorties sont émulées afin de présenter aux logiciels un environnement virtuel en apparence similaire à l’environnement réel. Il existe deux cas de figure : soit le périphérique est entièrement émulé (disque virtuel, carte graphique virtuelle), soit l’interface matérielle vers le périphérique est émulée par un driver et parfois partagée avec d’autres logiciels virtualisés (interface de communication, carte réseau). L’interface émulée ordonnance les accès aux périphériques entre machines virtuelles. Les auteurs de [10] nomment ce type de driver para pass-through .
Virtualisation matérielle des périphériques De plus en plus, les périphériques embarquent des fonctionnalités d’accélération matérielle de virtualisation de leurs fonctions. Une extension de la spécification du bus PCI Express a été notamment portée par Intel dans ce sens, appelée Single Root Input Output Virtualization (SR IOV) [11]. L’accélération matérielle de la virtualisation de ces fonctions minimise le goulot d’étranglement du débit causé par le processeur dans le cadre de l’émulation de périphérique complet ou de son interface matérielle. Ce support existe pour l’instant uniquement sur le bus PCI Express. Dans le cas des cartes réseau, la technologie SR-IOV permet d’optimiser la surcharge ajoutée par le partage des périphériques physiques par l’hyperviseur. Il est maintenant possible de définir un nombre donné de fonctions virtuelles PCI Express dans la carte réseau, que l’on associe à des machines virtuelles. Ces machines pourront directement communiquer avec les fonctions virtuelles via des accès mémoire directs, pour configurer l’envoi et la réception de trames Ethernet ainsi que les interruptions. Pour la réception d’une trame Ethernet, l’identification de la machine virtuelle à interrompre sera effectuée directement au niveau de la carte réseau, grâce aux adresses MAC associées aux différentes fonctions virtuelles. Ainsi le gestionnaire de machines virtuelles n’a plus à être interrompu en premier pour router logiciellement l’interruption vers la machine virtuelle destinataire. Cette méthode permet d’obtenir une véritable bande passante dix Giga bits dans un environnement virtuel.
Mise en œuvre des machines virtuelles
Une machine virtuelle doit posséder certaines caractéristiques qui contraignent les techniques de virtualisation que l’on peut utiliser pour mettre en œuvre ce concept:
1. Correspondre à la copie d’une machine physique ;
2. Être performante ;
3. Son exécution doit être contrôlée par un gestionnaire de machines virtuelles.
Les gestionnaires de machines virtuelles utilisés dans les architectures cloud en production aujourd’hui utilisent donc un sous-ensemble des techniques de virtualisation citées précédemment :
— Dans la plupart des cas, la virtualisation matérielle de cœurs de processeur.
— La virtualisation de périphériques via l’émulation ou un support matériel dans le périphérique lui-même, notamment pour les fonctionnalités d’affichage de stockage et des communications réseau.
— La virtualisation matérielle de la mémoire (cœurs et périphériques).
— La virtualisation matérielle des interruptions.
Nous excluons de nos travaux les machines virtuelles ne rentrant pas dans la catégorie (1), comme les machines liées aux langages Java et .NET. Enfin, en ce qui concerne le type de virtualisation, la paravirtualisation et la virtualisation complète sont toutes deux utilisées, et ce parfois ensemble dans un même projet (Xen [12]). Les logiciels qui mettent en œuvre ces techniques afin de supporter l’exécution des machines virtuelles sont les gestionnaires de machines virtuelles, que nous avons déjà abordés à plusieurs reprises dans ce manuscrit. La section suivante présente les différents types existants.
|
Table des matières
Introduction
1 Contexte scientifique et État de l’art
1.1 Le cloud computing
1.1.1 Caractéristiques essentielles du cloud
1.1.2 Les acteurs des systèmes cloud
1.2 Virtualisation et machines virtuelles
1.2.1 Types de virtualisation
1.2.2 Techniques de virtualisation
1.2.3 Mise en œuvre des machines virtuelles
1.3 Gestionnaires de machines virtuelles
1.3.1 Architecture
1.3.2 Fonctionnement et rôle de l’hyperviseur
1.4 Vulnérabilités et attaques
1.4.1 Terminologie de la sécurité informatique
1.4.2 Problèmes de sécurité apportés par la virtualisation
1.4.3 Modèle de menaces
1.4.4 Attaques des systèmes virtualisés
1.5 La sécurité dans les architectures virtualisées
1.5.1 Surveillance des machines virtuelles
1.5.2 Renforcement de l’isolation
1.5.3 Vulnérabilité du logiciel et confiance dans le matériel
1.6 Objectifs de la thèse
2 Étude des architectures matérielles actuelles
2.1 Introduction
2.2 Les processeurs Intel récents
2.3 Mécanismes d’isolation et de contrôle d’accès
2.3.1 Les cœurs
2.3.2 Interconnexion du processeur
2.3.3 Interconnexion des périphériques
2.3.4 Démarrage et chaîne de confiance
2.4 Rappels techniques
2.4.1 Détails sur l’architecture Intel 64
2.4.2 Extension matérielle d’assistance à la virtualisation
2.4.3 Interconnexion des périphériques
2.5 Conclusion
3 Architecture de sécurité
3.1 Introduction
3.2 Modèle de menaces et hypothèses
3.3 Attestation de code et racine de confiance dynamique
3.4 Vue d’ensemble de l’approche proposée
3.4.1 Infrastructure matérielle
3.4.2 Périphérique de confiance
3.4.3 Hyperviseur de sécurité
3.5 Cycle de test d’intégrité
3.5.1 Les challenges
3.5.2 Les tests d’environnement
3.5.3 Tests d’intégrité du logiciel observé
3.6 Intégrité de l’hyperviseur de sécurité
3.6.1 Espace mémoire et chargement
3.6.2 Modes et niveaux de privilèges
3.6.3 Gestion de la mémoire et des caches
3.6.4 Compteurs et fréquence de fonctionnement
3.6.5 Gestion des interruptions externes
3.6.6 Gestion des périphériques
3.6.7 Isolation
3.7 Conception des challenges et tests d’environnement
3.7.1 Expressivité des tests d’environnement
3.7.2 Expressivité des challenges
3.7.3 Détermination du temps d’exécution
3.7.4 Vérification des caractéristiques de l’hyperviseur de sécurité
3.7.5 Détection de l’émulation ou de la virtualisation de l’hyperviseur
3.8 Conclusion
4 Mise en œuvre
4.1 Introduction
4.2 Périphérique de confiance
4.2.1 Prototypage de périphérique PCI Express
4.2.2 SoC Milkymist
4.2.3 Conception du SoC pour le périphérique de confiance
4.2.4 Un coprocesseur d’automates
4.2.5 Développement de l’interface PCI Express
4.2.6 Conclusion
4.3 Hyperviseur de sécurité
4.3.1 Stratégie de chargement et initialisation
4.3.2 Exécution des machines virtuelles
4.3.3 Gestion de la récursivité
4.3.4 Contrôle et débogage
4.3.5 Bibliothèque d’hyperviseur
4.3.6 Mise en œuvre de l’hyperviseur de sécurité
4.4 Le cycle de tests d’intégrité
4.4.1 Mise en œuvre des challenges
4.4.2 Mise en œuvre des tests d’intégrité
4.5 Conclusion
5 Efficacité et performances
Conclusion
