Sécurité

Pour empêcher l'exécution de charges utiles arbitraires dans une pVM, Android Virtualization Framework (AVF) utilise une approche de sécurité en couches où chaque couche ajoute des mesures d'application supplémentaires. Voici une liste des couches de sécurité AVF :

• Android – Android garantit que seules les applications disposant d'autorisations pVM sont autorisées à créer ou à inspecter des pVM.

• Bootloader - Le bootloader garantit que seules les images pVM signées par Google ou les fournisseurs d'appareils sont autorisées à démarrer et respectent la procédure de démarrage vérifié d'Android . Cette architecture implique que les applications exécutant des pVM ne peuvent pas regrouper leurs propres noyaux.

• pVM – La pVM fournit une défense en profondeur, comme avec SELinux , pour les charges utiles exécutées dans la pVM. La défense en profondeur interdit le mappage des données en tant qu'exécutables ( neverallow execmem ) et garantit que W^X est valable pour tous les types de fichiers.

Modèle de sécurité

La confidentialité, l'intégrité et la disponibilité, également connue sous le nom de triade CIA, est un modèle conçu pour guider les politiques de sécurité de l'information :

• La confidentialité est un ensemble de règles qui limitent l'accès à l'information.
• L'intégrité est l'assurance que les informations sont fiables et exactes.
• La disponibilité est une garantie d'accès fiable aux informations par les entités autorisées.

Notez que pKVM a été conçu pour maintenir la confidentialité et l'intégrité, mais pas la disponibilité, des invités. Ces principes influencent les décisions de conception couvrant tous les aspects de l'architecture, de l'hyperviseur aux composants de l'espace utilisateur.

Confidentialité et intégrité

La confidentialité découle des propriétés d'isolation de la mémoire appliquées par l'hyperviseur pKVM. pKVM suit la propriété de la mémoire des pages de mémoire physique individuelles et toutes les demandes des propriétaires de pages à partager. pKVM garantit que seules les pVM autorisées (hôte et invités) ont la page donnée mappée dans leurs tables de pages de l'étape 2 qui sont contrôlées par l'hyperviseur. Cette architecture maintient que le contenu de la mémoire appartenant à une pVM reste privé à moins que le propriétaire ne la partage explicitement avec une autre pVM.

Les restrictions pour le maintien de la confidentialité s'étendent également à toutes les entités du système qui effectuent des accès à la mémoire au nom des pVM, à savoir les appareils et services compatibles DMA s'exécutant dans des couches plus privilégiées . Les fournisseurs de SoC doivent satisfaire à un nouvel ensemble d'exigences avant de pouvoir prendre en charge pKVM, sinon la confidentialité ne peut pas être assurée.

L'intégrité s'applique à la fois aux données en mémoire et au calcul :

• Les pVM ne peuvent pas modifier la mémoire de l'autre sans consentement.
• Les pVM ne peuvent pas s'influencer mutuellement sur l'état du CPU.

Ces exigences sont appliquées par l'hyperviseur. Mais des problèmes concernant l'intégrité des données se posent également avec le stockage virtuel des données où d'autres solutions doivent être appliquées, telles que dm-verity ou AuthFS.

Ces principes ne sont pas différents de l'isolation des processus offerte par Linux où l'accès aux pages mémoire est contrôlé avec des tables de pages de niveau 1 et les changements de contexte du noyau entre les processus. Cependant, la partie EL2 de pKVM, qui applique ces propriétés, a environ la moitié de la surface d'attaque par rapport à l'ensemble du noyau Linux (environ 10 000 contre 20 millions de lignes de code) et offre donc une meilleure assurance pour utiliser des cas trop sensibles pour s'y fier. sur l'isolement du processus.

Compte tenu de sa taille, un pKVM se prête à une vérification formelle. Nous soutenons activement la recherche universitaire, qui vise à prouver formellement ces propriétés sur le binaire pKVM réel.

Le reste de ce document couvre les garanties de confidentialité et d'intégrité que chaque composant autour d'un pKVM fournit.

Hyperviseur

pKVM est un hyperviseur basé sur KVM qui isole les pVM et Android dans des environnements d'exécution mutuellement méfiants. Ces propriétés sont valables en cas de compromission au sein de n'importe quelle pVM, y compris l'hôte. Les hyperviseurs alternatifs conformes à AVF doivent fournir des propriétés similaires.

• Une pVM ne peut pas accéder à une page appartenant à une autre entité, telle qu'une pVM ou un hyperviseur, à moins qu'elle ne soit explicitement partagée par le propriétaire de la page. Cette règle inclut la pVM hôte et s'applique aux accès CPU et DMA.
• Avant qu'une page utilisée par une pVM ne soit renvoyée à l'hôte, comme lorsque la pVM est détruite, elle est effacée.
• La mémoire de toutes les pVM et du micrologiciel pVM d'un démarrage de périphérique est effacée avant que le chargeur de démarrage du système d'exploitation ne s'exécute lors du démarrage de périphérique suivant.
• Lorsqu'un débogueur matériel, tel que SJTAG, est connecté, une pVM ne peut pas accéder à ses clés précédemment créées.
• Le micrologiciel pVM ne démarre pas s'il ne peut pas vérifier l'image initiale.
• Le micrologiciel pVM ne démarre pas si l'intégrité de l' instance.img est compromise.
• La chaîne de certificats de démarrage (BCC) et les identificateurs de périphérique composés (CDI) fournis à une instance de pVM ne peuvent être dérivés que par cette instance particulière.

Système d'exploitation invité

Microdroid est un exemple de système d'exploitation exécuté dans une pVM. Microdroid se compose d'un chargeur de démarrage basé sur U-boot, GKI, et d'un sous-ensemble d'espace utilisateur Android, et d'un lanceur de charge utile. Ces propriétés sont valables en cas de compromission au sein de n'importe quelle pVM, y compris l'hôte. Les systèmes d'exploitation alternatifs exécutés dans une pVM doivent fournir des propriétés similaires.

• Microdroid ne démarrera pas si boot.img , super.img , vbmeta.img ou vbmeta\_system.img ne peuvent pas être vérifiés.
• Microdroid ne démarrera pas si la vérification APK échoue.
• La même instance de Microdroid ne démarrera pas même si l'APK a été mis à jour.
• Microdroid ne démarrera pas si l'un des APEX échoue à la vérification.
• Microdroid ne démarrera pas (ou démarrera avec un état initial propre) si le fichier instance.img est modifié en dehors de la pVM invitée.
• Microdroid fournit une attestation à la chaîne de démarrage.
• Toute modification (non signée) des images disque partagées avec la pVM invitée provoque une erreur d'E/S côté pVM.
• BCC et CDI fournis à une instance de pVM ne peuvent être dérivés que par cette instance particulière.

Android

Ce sont des propriétés gérées par Android en tant qu'hôte, mais qui ne sont pas valables en cas de compromission de l'hôte :

• Une pVM invitée ne peut pas interagir directement avec (par exemple, établir une connexion vsock avec) d'autres pVM invitées.
• Seul le VirtualizationService dans la pVM hôte peut créer un canal de communication vers une pVM (Remarque : il peut transmettre le canal établi à d'autres).
• Seules les applications signées avec la clé de plate-forme peuvent demander l'autorisation de créer, de posséder ou d'interagir avec des pVM.
• L'identifiant, appelé identificateur de contexte (CID) , utilisé lors de la configuration des connexions vsock entre l'hôte et la pVM n'est pas réutilisé pendant l'exécution de la pVM hôte. Par exemple, remplacer une pVM en cours d'exécution par une autre n'est pas possible.

Disponibilité

Dans le contexte des pVM, la disponibilité fait référence au fait que l'hôte alloue suffisamment de ressources aux invités pour que les invités puissent effectuer les tâches pour lesquelles ils ont été conçus.

Les responsabilités de l'hôte incluent la planification des processeurs virtuels de la pVM. KVM, contrairement aux hyperviseurs traditionnels de type 1, tels que Xen, prend la décision de conception explicite de déléguer la planification de la charge de travail au noyau hôte. Compte tenu de la taille et de la complexité des planificateurs actuels, cette décision de conception réduit considérablement la taille de la base informatique de confiance (TCB) et permet à l'hôte de prendre des décisions de planification plus éclairées pour optimiser les performances. Cependant, un hôte malveillant peut choisir de ne jamais planifier d'invité.

De même, pKVM délègue également la gestion des interruptions physiques au noyau hôte pour réduire la complexité de l'hyperviseur et laisser l'hôte responsable de la planification. Des efforts sont faits pour s'assurer que la transmission des interruptions d'invité n'entraîne qu'un déni de service (trop peu, trop d'interruptions ou mal acheminées).

Enfin, le processus de surveillance de machine virtuelle (VMM) de l'hôte est chargé d'allouer de la mémoire et de fournir des périphériques virtuels, tels qu'une carte réseau. Un VMM malveillant peut retenir des ressources de l'invité.

Bien que pKVM ne fournisse pas de disponibilité aux invités, la conception protège la disponibilité de l'hôte contre les invités malveillants, car l'hôte peut toujours anticiper ou résilier un invité et récupérer ses ressources.

Démarrage sécurisé

Les données sont liées aux instances d'une pVM et le démarrage sécurisé garantit que l'accès aux données d'une instance peut être contrôlé. Le premier démarrage d'une instance la provisionne en générant de manière aléatoire un sel secret pour la pVM et en extrayant des détails, tels que des clés publiques de vérification et des hachages, à partir des images chargées. Ces informations sont utilisées pour vérifier les démarrages ultérieurs de l'instance pVM et garantir que les secrets de l'instance ne sont divulgués qu'aux images qui réussissent la vérification. Ce processus se produit pour chaque étape de chargement dans la pVM : firmware pVM, pVM ABL, Microdroid, etc.

DICE fournit à chaque étape de chargement une paire de clés d'attestation, dont la partie publique est certifiée dans l'entrée BCC pour cette étape. Cette paire de clés peut changer entre les démarrages, de sorte qu'un secret de scellement est également dérivé, qui est stable pour l'instance de VM lors des redémarrages et, en tant que tel, convient pour protéger l'état persistant. Le secret de scellement est très précieux pour la machine virtuelle, il ne doit donc pas être utilisé directement. Au lieu de cela, les clés de scellement doivent être dérivées du secret de scellement et le secret de scellement doit être détruit le plus tôt possible.

Chaque étape transmet un objet CBOR codé de manière déterministe à l'étape suivante. Cet objet contient des secrets et le BCC, qui contient des informations d'état accumulées, par exemple si la dernière étape a été chargée en toute sécurité.

Appareils déverrouillés

Lorsqu'un appareil est déverrouillé avec fastboot oem unlock , les données utilisateur sont effacées. Ce processus protège les données des utilisateurs contre tout accès non autorisé. Les données privées d'une pVM sont également invalidées lorsqu'un déverrouillage d'appareil se produit.

Une fois déverrouillé, le propriétaire de l'appareil est libre de reflasher les partitions qui sont généralement protégées par un démarrage vérifié, y compris les partitions contenant l'implémentation pKVM. Par conséquent, pKVM sur un appareil déverrouillé ne sera pas fiable pour maintenir le modèle de sécurité.

Les parties distantes peuvent observer cet état potentiellement non sécurisé en inspectant l' état de démarrage vérifié de l'appareil dans un certificat d'attestation de clé.