Sécurité

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

• Android s'assure 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 de PV signées par Google ou les fournisseurs d'appareils sont autorisées à démarrer et respecte la procédure Android Verified Boot. Cette architecture implique que les applications exécutant des VM protégées ne peuvent pas regrouper leurs propres noyaux.

• Les pVM offrent une défense en profondeur, par exemple 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 s'applique à tous les types de fichiers.

Modèle de sécurité

La confidentialité, l'intégrité et la disponibilité (triade CIA) constituent un modèle conçu pour guider les règles de sécurité des informations :

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

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 de partage de pages par les propriétaires. pKVM s'assure que seules les pVM autorisées (hôte et invités) ont la page donnée mappée dans leurs tables de pages de niveau 2 contrôlées par l'hyperviseur. Cette architecture maintient que le contenu de la mémoire appartenant à une pVM reste privé, sauf si le propriétaire le partage explicitement avec une autre pVM.

Les restrictions visant à préserver la confidentialité s'étendent également à toutes les entités du système qui effectuent des accès mémoire au nom des VM protégées, à savoir les appareils compatibles avec DMA et les services s'exécutant dans des couches plus privilégiées. Les fournisseurs de systèmes sur puce (SoC) doivent répondre à 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 aux données en mémoire et aux calculs. Les pVM ne peuvent pas :

• Modifier la mémoire d'une autre personne sans son consentement
• influencer l'état du processeur de l'autre.

Ces exigences sont appliquées par l'hyperviseur. Toutefois, des problèmes d'intégrité des données se posent également avec le stockage de données virtuel lorsque 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 où le noyau effectue des changements de contexte entre les processus. Toutefois, la partie EL2 de pKVM, qui applique ces propriétés, présente une surface d'attaque trois ordres de grandeur inférieure à celle de l'ensemble du noyau Linux (environ 10 000 lignes de code contre 20 millions). Elle offre donc une assurance plus forte pour les cas d'utilisation trop sensibles pour s'appuyer sur l'isolation des processus.

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

Le reste de cette page aborde les garanties de confidentialité et d'intégrité fournies par chaque composant autour d'un pKVM.

Hyperviseur

pKVM est un hyperviseur basé sur KVM qui isole les pVM et Android dans des environnements d'exécution mutuellement non fiables. Ces propriétés sont valables en cas de compromission dans n'importe quelle VM protégée, y compris l'hôte. Les hyperviseurs alternatifs compatibles avec AVF doivent fournir des propriétés similaires.

• Une VM préemptive ne peut pas accéder à une page appartenant à une autre entité, telle qu'une VM préemptive ou un hyperviseur, à moins que le propriétaire de la page ne l'ait explicitement partagée. Cette règle inclut le pVM hôte et s'applique aux accès au processeur et au DMA.

• Avant qu'une page utilisée par une VM protégée ne soit renvoyée à l'hôte, par exemple lorsque la VM protégée est détruite, elle est effacée.

• La mémoire de toutes les pVM et du micrologiciel pVM d'un démarrage de l'appareil est effacée avant l'exécution du bootloader de l'OS lors du démarrage suivant de l'appareil.

• Lorsqu'un débogueur matériel, tel que SJTAG, est associé, une pVM ne peut pas accéder à ses clés précédemment générées.

• Le micrologiciel de la pVM ne démarre pas s'il ne peut pas valider l'image initiale.

• Le micrologiciel de la pVM ne démarre pas si l'intégrité de instance.img est compromise.

• La chaîne de certificats DICE et les identifiants d'appareil composés (CDI) fournis à une instance pVM ne peuvent être dérivés que par cette instance spécifique.

OS invité

Microdroid est un exemple d'OS s'exécutant dans une VM protégée. Microdroid se compose d'un bootloader basé sur U-boot, d'un GKI, 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 dans une pVM, y compris l'hôte. Les OS alternatifs exécutés dans une VM paravirtualisée devraient 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 validés.

• Microdroid ne démarrera pas si la validation de l'APK échoue.

• La même instance Microdroid ne démarrera pas, même si l'APK a été mis à jour.

• Microdroid ne démarrera pas si la validation de l'un des APEX échoue.

• Microdroid ne démarrera pas (ou démarrera avec un état initial propre) si 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) apportée aux images de disque partagées avec la pVM invitée entraîne une erreur d'E/S côté pVM.

• La chaîne de certificats DICE et les CDI fournis à une instance pVM ne peuvent être dérivés que par cette instance spécifique.

• Les écritures dans un volume de stockage chiffré sont confidentielles, mais il n'existe aucune protection contre la restauration au niveau d'un bloc de chiffrement. De plus, toute autre falsification externe arbitraire d'un bloc de données entraîne l'affichage de ce bloc comme un bloc de données inutiles pour Microdroid, plutôt que d'être détecté explicitement comme une erreur d'E/S.

Android

Il s'agit de 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 VM invitée ne peut pas interagir directement avec d'autres VM invitées (par exemple, pour établir une connexion vsock).

• Seul le VirtualizationService du pVM hôte peut créer un canal de communication vers un pVM.

• Seules les applications signées avec la clé de plate-forme peuvent demander l'autorisation de créer des pVM, d'en être propriétaires ou d'interagir avec elles.

• L'identifiant, appelé identifiant de contexte (CID), utilisé pour configurer les connexions vsock entre l'hôte et la pVM n'est pas réutilisé lorsque la pVM hôte est en cours d'exécution. Par exemple, vous ne pouvez pas remplacer une VM parallèle en cours d'exécution par une autre.

Disponibilité

Dans le contexte des VM protégées, la disponibilité fait référence à l'hôte qui alloue suffisamment de ressources aux invités pour qu'ils puissent effectuer les tâches pour lesquelles ils sont conçus.

L'hôte est responsable de la planification des processeurs virtuels de la VM protégée. Contrairement aux hyperviseurs de type 1 classiques (comme Xen), KVM délègue explicitement la planification des charges 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 de calcul sécurisée (TCB, Trusted Computing Base) et permet à l'hôte de prendre des décisions de planification plus éclairées pour optimiser les performances. Toutefois, 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. Nous nous efforçons de faire en sorte que le transfert des interruptions des invités n'entraîne qu'un refus de service (interruptions trop peu nombreuses, trop nombreuses ou mal acheminées).

Enfin, le processus du moniteur 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 préempter ou mettre fin à un invité et récupérer ses ressources.

Démarrage sécurisé

Les données sont liées aux instances d'une VM parallèle, 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 VM protégée et en extrayant des détails, tels que les clés publiques et les hachages de validation, à partir des images chargées. Ces informations sont utilisées pour vérifier les démarrages ultérieurs de l'instance de VM protégée et s'assurer 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 : micrologiciel de la pVM, ABL de la pVM, Microdroid, etc.

DICE fournit à chaque étape de chargement une paire de clés d'attestation, dont la partie publique est certifiée dans le certificat DICE pour cette étape. Cette paire de clés peut changer entre les démarrages. Un secret de scellement est donc également dérivé. Il est stable pour l'instance de VM lors des redémarrages et, à ce titre, convient à la protection de l'état persistant. Le secret de scellement est très important pour la VM. 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 encodé de manière déterministe à l'étape suivante. Cet objet contient des secrets et la chaîne de certificats DICE, qui contient des informations sur l'état cumulé, par exemple si la dernière étape s'est chargée de manière sécurisée.

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 utilisateur contre les accès non autorisés. Les données privées d'une VM protégée sont également invalidées lors du déverrouillage d'un appareil.

Une fois déverrouillé, le propriétaire de l'appareil est libre de reflasher les partitions habituellement protégées par le démarrage sécurisé, y compris celles contenant pvmfw et l'implémentation pKVM. Par conséquent, un appareil déverrouillé n'est pas considéré comme fiable pour respecter le modèle de sécurité d'une VM protégée.

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é.