3.3 Architectures sécurisées existantes . . . . 42 3.4 Conclusion . . . . 56
Chapitre 3. État de l’art
Ce chapitre présente les travaux relatifs à l’hypervision et à la sécurisation d’environnements d’exécution. Dans la section 3.1, les différents types d’hyperviseurs existants seront présentés, et nous définirons les caractéristiques nécessaires à un hyperviseur pour répondre à notre problématique. Ensuite, nous étudierons dans la section 3.2 les extensions matérielles de virtualisation existantes, à savoir les solutions développées par Intel, AMD et ARM. Finalement, nous présenterons dans la sec-tion 3.3 différentes architectures sécurisées qui cherchent à répondre à la problématique d’exécusec-tion sécurisée de machines virtuelles.
3.1 Hyperviseurs
L’hyperviseur est un élément important de la virtualisation, car celui-ci est généralement uti-lisé pour gérer les différents systèmes d’exploitation invités s’exécutant sur une même plate-forme [36, 37]. C’est un agent logiciel situé entre le matériel et les systèmes d’exploitation virtualisés, qui est en charge d’allouer les ressources matérielles aux systèmes d’exploitation invités. Par son rôle, l’hyperviseur est un élément critique en terme de sécurité puisque chaque faille présente dans l’hyperviseur peut mener à un ou plusieurs des points suivants :
– lectures non autorisées de données d’une machine virtuelle (violation de confidentialité) ; – modifications non autorisées de données d’une machine virtuelle (violation d’intégrité) ; – fuites d’informations – données présentes en mémoire ou dans les composants matériels qui
peuvent être exploitées ensuite par une autre machine virtuelle malveillante.
De ce fait, l’hyperviseur doit être dans la Trusted Computing Base, i.e. dans les éléments de confiance au sein du système. C’est pourquoi il est primordial que les hyperviseurs demeurent aussi petits que possible, pour ainsi minimiser les risques d’être compromis. R. J. Masti et al. [38] défi-nissent deux propriétés concernant la sensibilité de l’hyperviseur aux attaques : le fait d’avoir une faible empreinte et le fait d’avoir une interaction réduite avec les machines virtuelles. L’empreinte est généralement mesurée en termes de lignes de code (LoC). En effet, avoir moins de lignes de code signifie contenir moins de bugs en moyenne, et ainsi moins de possibilités pour un attaquant d’ex-ploiter une faille. En utilisant des extensions matérielles dédiées à la virtualisation, les hyperviseurs peuvent atteindre des tailles de 4 000 LoC [39] tandis qu’un hyperviseur implémentant tous les mé-canismes de virtualisation atteint des tailles de 100 000 LoC [40].
Les interactions entre l’hyperviseur et les systèmes d’exploitation invités ont lieu au démarrage et à l’arrêt d’une machine virtuelle, ainsi qu’à chaque fois qu’une machine virtuelle requiert un ser-vice depuis l’hyperviseur, comme par exemple lors d’un accès aux périphériques d’entrée/sortie. On parle de principe de désengagement de l’hyperviseur lorsque l’on réduit ses interactions avec les ma-chines virtuelles au minimum, i.e. le démarrage et l’arrêt des mama-chines virtuelles. Cela permet alors de réduire les possibilités pour un attaquant d’exploiter une faille dans les fonctions de l’hyperviseur.
Chapitre 3. État de l’art
C
0C
nC
0C
nHyperviseur
OS
0OS
nOS
0OS
nH H
Hyperviseur Type-1 Hyperviseur Distribué Hyperviseur DédiéC
0Cn
H OS
0OS
nC
1 Hyperviseur DésengagéC
0Cn
H
OS
0OS
nC
1H H
FIGURE3.1 – Les différents types d’hyperviseurs
Source : R.J.Masti et al. [38]
Les hyperviseurs peuvent être classifiés en plusieurs catégories, présentées dans les sous-sections suivantes.
3.1.1 Hyperviseurs traditionnels
L’hyperviseur traditionnel, dit de type T1 (figure 3.1), est un hyperviseur composé d’une seule instance gérant intégralement toutes les ressources de la plateforme et interagissant fréquemment avec les machines virtuelles. Par exemple, chaque interruption d’entrée/sortie déclenche un change-ment de contexte vers l’hyperviseur. D’autres interactions peuvent être requises, en particulier pour la gestion de la mémoire s’il n’y a pas d’extension matérielle dédiée à la virtualisation, ce qui inclut un mode de privilège additionnel dans le cœur, combiné avec une extension de la MMU pour traduire les adresses machines en adresses physiques. De tels hyperviseurs nécessitent beaucoup de modifi-cations matérielles pour réduire leurs interactions avec les machines virtuelles. Les hyperviseurs de type T1 sont les plus utilisés, et nous pouvons par exemple citer Xen [41] ou VMware [42]. Cepen-dant, ils ne répondent pas aux deux critères évoqués précédemment, à savoir une faible empreinte et une faible interaction avec les machines virtuelles. En effet, même s’il est possible de réduire la taille des hyperviseurs en utilisant des extensions matérielles pour la virtualisation, la plupart de ces hy-perviseurs possèdent 100 000 lignes de codes lorsqu’ils utilisent les techniques de para-virtualisation ou de binary translation. En ce qui concerne le principe de faible interaction, ces hyperviseurs, par conception, ne peuvent pas être satisfaisants.
3.1.2 Hyperviseurs distribués
Les hyperviseurs distribués consistent en plusieurs instances d’hyperviseurs où toutes sont en charge d’un sous-ensemble de l’architecture (figure 3.1). Comme pour les hyperviseurs de type T1, de tels hyperviseurs sont en charge du matériel et offrent une interface pour les accès aux périphé-riques. Ceci rend impossible une interaction minimale entre les machines virtuelles et l’hyperviseur.
Chapitre 3. État de l’art
Les hyperviseurs distribués utilisent les mêmes concepts que les systèmes d’exploitation dits multi-kernel [43, 44, 45]. Ce type de système d’exploitation vise à répondre aux problèmes de passage à l’échelle liés aux architectures comportant de plus en plus de cœurs. W. Shi et al. proposent Multi-Hype [46] comme hyperviseur distribué, dont les principaux avantages comparé aux hyperviseurs dits monolithiques sont le gain en performance dans le cas d’un déploiement sur une plateforme many-core (de part le concept de multi-kernel) et surtout des garanties de sécurité accrues. En effet, l’hyperviseur étant confiné dans plusieurs instances, une corruption d’une instance de l’hyperviseur peut difficilement en corrompre une autre, réduisant ainsi la surface d’attaque de la plateforme.
3.1.3 Hyperviseurs dédiés
Les hyperviseurs dédiés [47] s’exécutent sur des cœurs dédiés et gèrent les systèmes invités s’exé-cutant sur les autres cœurs. Ce type d’hyperviseur ouvre la voie à la suppression de la couche de vir-tualisation en laissant les machines virtuelles s’exécuter nativement sur les cœurs de la plateforme. Surtout, ce type d’hyperviseur peut respecter le principe de désengagement. En effet, un hyperviseur dédié n’est pas obligé de s’exécuter sur les mêmes cœurs que ceux de la machine virtuelle.
Hyperviseurs désengagés
Les hyperviseurs désengagés sont un type d’hyperviseurs dédiés qui limitent les interactions entre les machines virtuelles et l’hyperviseur pendant leurs exécutions, en permettant aux machine virtuelles d’être elles-mêmes en charge du matériel sur lequel elles s’exécutent. Cela permet d’aug-menter la sécurité ainsi que la performance. Ces hyperviseurs peuvent à la fois avoir une faible em-preinte et des interactions réduites avec les machines virtuelles, mais ils nécessitent généralement des extensions matérielles pour prendre en charge l’isolation des machines virtuelles. Par exemple NoHype [48] est un hyperviseur qui s’exécute sur un cœur dédié et qui ne partage pas de cœurs avec les machines virtuelles. Au démarrage d’une machine virtuelle, NoHype envoie un signal au cœur de démarrage de la nouvelle machine virtuelle, qui vient alors exécuter un firmware permettant la configuration de l’isolation de la machine virtuelle.
Hyperviseurs aveugles
Les hyperviseurs aveugles, présentés par P.Dubrulle et al. [35], sont un type d’hyperviseurs dé-diés et désengagés qui cherchent à réduire la surface d’attaque de l’hyperviseur en lui interdisant d’accéder aux ressources matérielles allouées à une machine virtuelle une fois que celle-ci s’exécute. Les interactions entre l’hyperviseur et la machine virtuelle sont alors impossibles. L’hyperviseur peut
Chapitre 3. État de l’art
néanmoins arrêter la machine virtuelle, mais il ne peut pas accéder aux données de la machine vir-tuelle aussi bien pendant qu’après son exécution. Le concept d’hypervision en aveugle nécessite aussi des extensions matérielles.
3.1.4 Conclusion
Nous avons vu que les hyperviseurs sont en charge de la gestion des différentes machines vir-tuelles de la plateforme. Ils sont généralement responsables de la sécurité de la plateforme et leur rôle implique qu’ils peuvent être la cible d’attaques permettant de prendre le contrôle de l’intégra-lité de la plateforme. De plus, les hyperviseurs deviennent de plus en plus imposants en termes de lignes de code et donc cela induit nécessairement un nombre de failles grandissant. Plusieurs at-taques aujourd’hui [49, 50, 51] poussent à croire que les hyperviseurs doivent être repensés et limités, permettant ainsi de réduire la surface d’attaque. Pour cela nous avons définit deux caractéristiques : faible empreinte et interactions réduites. Nous avons aussi présenté les différents types d’hypervi-seurs existants. Seuls les hypervid’hypervi-seurs dédiés permettent de satisfaire ces deux caractéristiques. Nous pensons néanmoins qu’il est nécessaire de limiter au maximum les droits de l’hyperviseur, à savoir lui interdire l’accès aux ressources des machines virtuelles. C’est pourquoi nous explorerons dans notre travail le concept d’hyperviseur aveugle.