Architecture AVF

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Android fournit une implémentation de référence de tous les composants nécessaires à l'implémentation du framework de virtualisation Android. Actuellement, cette implémentation est limitée à ARM64. Cette page explique l'architecture du framework.

Arrière-plan

L'architecture Arm autorise jusqu'à quatre niveaux d'exception, le niveau d'exception 0 (EL0) étant le moins privilégié et le niveau d'exception 3 (EL3) le plus privilégié. La plus grande partie du codebase Android (tous les composants de l'espace utilisateur) s'exécute à EL0. Le reste de ce que l'on appelle communément "Android" est le noyau Linux, qui s'exécute à EL1.

La couche EL2 permet d'introduire un hyperviseur qui permet d'isoler la mémoire et les appareils dans des pVM individuels à EL1/EL0, avec de solides garanties de confidentialité et d'intégrité.

Hyperviseur

La machine virtuelle basée sur le kernel protégée (pKVM) est basée sur l'hyperviseur Linux KVM, qui a été étendu pour pouvoir limiter l'accès aux charges utiles exécutées dans les machines virtuelles invitées marquées comme "protégées" au moment de la création.

KVM/arm64 prend en charge différents modes d'exécution en fonction de la disponibilité de certaines fonctionnalités de processeur, à savoir les extensions d'hôte de virtualisation (VHE) (ARMv8.1 et versions ultérieures). Dans l'un de ces modes, communément appelé mode non-VHE, le code de l'hyperviseur est extrait de l'image du noyau au démarrage et installé à EL2, tandis que le noyau lui-même s'exécute à EL1. Bien qu'il fasse partie du codebase Linux, le composant EL2 de KVM est un petit composant chargé de la commutation entre plusieurs EL1. Le composant de l'hyperviseur est compilé avec Linux, mais se trouve dans une section de mémoire distincte et dédiée de l'image vmlinux. pKVM exploite cette conception en étendant le code de l'hyperviseur avec de nouvelles fonctionnalités lui permettant d'imposer des restrictions sur le noyau hôte Android et l'espace utilisateur, et de limiter l'accès de l'hôte à la mémoire invitée et à l'hyperviseur.

Modules de fournisseurs pKVM

Un module fournisseur pKVM est un module spécifique au matériel contenant des fonctionnalités spécifiques à l'appareil, telles que les pilotes de l'unité de gestion de la mémoire d'E/S (IOMMU). Ces modules vous permettent de porter des fonctionnalités de sécurité nécessitant un accès de niveau 2 (EL2) vers le pKVM.

Pour savoir comment implémenter et charger un module de fournisseur pKVM, consultez la page Implémenter un module de fournisseur pKVM.

Procédure de démarrage

La figure suivante illustre la procédure de démarrage de pKVM:

1. Le bootloader entre dans le noyau générique à EL2.
2. Le kernel générique détecte qu'il s'exécute à EL2 et se déprivilège à EL1, tandis que le pKVM et ses modules continuent de s'exécuter à EL2. De plus, les modules du fournisseur pKVM sont chargés à ce moment-là.
3. Le noyau générique démarre normalement, en chargeant tous les pilotes de périphériques nécessaires jusqu'à atteindre l'espace utilisateur. À ce stade, le pKVM est en place et gère les tables de pages de l'étape 2.

La procédure de démarrage ne fait confiance au bootloader que pour préserver l'intégrité de l'image du noyau au début du démarrage. Lorsque le kernel est déprivilégié, il n'est plus considéré comme fiable par l'hyperviseur, qui est alors chargé de se protéger même si le kernel est compromis.

Le fait de placer le noyau Android et l'hyperviseur dans la même image binaire permet une interface de communication très étroitement couplée entre eux. Ce couplage étroit garantit des mises à jour atomiques des deux composants, ce qui évite de devoir maintenir l'interface entre eux stable et offre une grande flexibilité sans compromettre la maintenabilité à long terme. Le couplage étroit permet également d'optimiser les performances lorsque les deux composants peuvent coopérer sans affecter les garanties de sécurité fournies par l'hyperviseur.

De plus, l'adoption de GKI dans l'écosystème Android permet automatiquement de déployer l'hyperviseur pKVM sur les appareils Android dans le même binaire que le noyau.

Protection de l'accès à la mémoire du processeur

L'architecture Arm spécifie une unité de gestion de la mémoire (MMU) divisée en deux étapes indépendantes, qui peuvent toutes deux être utilisées pour implémenter la traduction d'adresses et le contrôle des accès à différentes parties de la mémoire. La MMU de l'étape 1 est contrôlée par EL1 et permet un premier niveau de traduction d'adresse. Linux utilise la MMU de l'étape 1 pour gérer l'espace d'adressage virtuel fourni à chaque processus d'espace utilisateur et à son propre espace d'adressage virtuel.

La MMU de l'étape 2 est contrôlée par EL2 et permet d'appliquer une deuxième traduction d'adresse sur l'adresse de sortie de la MMU de l'étape 1, ce qui génère une adresse physique (PA). La traduction de l'étape 2 peut être utilisée par les hyperviseurs pour contrôler et traduire les accès à la mémoire de toutes les VM invitées. Comme illustré dans la figure 2, lorsque les deux étapes de traduction sont activées, l'adresse de sortie de l'étape 1 est appelée adresse physique intermédiaire (IPA). Remarque: L'adresse virtuelle (AV) est traduite en IPA, puis en adresse physique (AP).

Historiquement, KVM s'exécute avec la traduction de l'étape 2 activée lors de l'exécution des invités et avec l'étape 2 désactivée lors de l'exécution du noyau Linux hôte. Cette architecture permet aux accès mémoire de la MMU d'étape 1 de l'hôte de passer par la MMU d'étape 2, ce qui permet un accès illimité de l'hôte aux pages de mémoire invitée. D'autre part, pKVM active la protection de l'étape 2 même dans le contexte de l'hôte et charge l'hyperviseur de protéger les pages de mémoire invitée au lieu de l'hôte.

KVM exploite pleinement la traduction d'adresses à l'étape 2 pour implémenter des mappages IPA/PA complexes pour les invités, ce qui crée l'illusion d'une mémoire contiguë pour les invités malgré la fragmentation physique. Toutefois, l'utilisation de la MMU de l'étape 2 pour l'hôte est limitée au contrôle d'accès uniquement. L'étape 2 de l'hôte est mappée par identité, ce qui garantit que la mémoire contiguë dans l'espace IPA de l'hôte est contiguë dans l'espace PA. Cette architecture permet d'utiliser de grands mappages dans la table des pages et réduit ainsi la pression sur le tampon de traduction (TLB). Étant donné qu'un mappage d'identité peut être indexé par PA, l'étape 2 de l'hôte est également utilisée pour suivre la propriété des pages directement dans la table des pages.

Protection de l'accès direct à la mémoire (DMA)

Comme décrit précédemment, le désappariement des pages invitées de l'hôte Linux dans les tables de pages du processeur est une étape nécessaire, mais insuffisante pour protéger la mémoire invitée. pKVM doit également se protéger contre les accès à la mémoire effectués par des appareils compatibles avec la DMA sous le contrôle du noyau hôte, ainsi que contre la possibilité d'une attaque DMA lancée par un hôte malveillant. Pour empêcher un tel appareil d'accéder à la mémoire invitée, pKVM nécessite un matériel IOMMU (Input-Output Memory Management Unit) pour chaque appareil compatible avec DMA du système, comme illustré à la figure 3.

Au minimum, le matériel IOMMU permet d'accorder et de révoquer l'accès en lecture/écriture d'un appareil à la mémoire physique avec une granularité de page. Toutefois, ce matériel IOMMU limite l'utilisation des appareils dans les pVM, car ils supposent une étape 2 mappée sur l'identité.

Pour assurer l'isolation entre les machines virtuelles, les transactions de mémoire générées pour le compte de différentes entités doivent être distinguables par l'IOMMU afin que l'ensemble approprié de tables de pages puisse être utilisé pour la traduction.

De plus, réduire la quantité de code spécifique au SoC au niveau EL2 est une stratégie clé pour réduire la base de calcul sécurisée (TCB) globale du pKVM et s'oppose à l'inclusion de pilotes IOMMU dans l'hyperviseur. Pour atténuer ce problème, l'hôte en EL1 est responsable des tâches de gestion auxiliaire de l'IOMMU, telles que la gestion de l'alimentation, l'initialisation et, le cas échéant, la gestion des interruptions.

Toutefois, le fait de laisser l'hôte contrôler l'état de l'appareil impose des exigences supplémentaires à l'interface de programmation du matériel IOMMU pour s'assurer que les vérifications d'autorisation ne peuvent pas être contournées par d'autres moyens, par exemple après une réinitialisation de l'appareil.

L'architecture de l'unité de gestion de la mémoire système (SMMU, System Memory Management Unit) d'Arm est un IOMMU standard et bien pris en charge pour les appareils Arm qui permet à la fois l'isolation et l'attribution directe. Il s'agit de la solution de référence recommandée.

Propriété de la mémoire

Au démarrage, toute mémoire autre que l'hyperviseur est supposée appartenir à l'hôte et est suivie en tant que telle par l'hyperviseur. Lorsqu'une pVM est créée, l'hôte donne des pages de mémoire pour lui permettre de démarrer, et l'hyperviseur transfère la propriété de ces pages de l'hôte à la pVM. Ainsi, l'hyperviseur met en place des restrictions de contrôle des accès dans la table des pages de l'hôte de l'étape 2 pour l'empêcher d'accéder à nouveau aux pages, ce qui garantit la confidentialité à l'invité.

La communication entre l'hôte et les invités est rendue possible par un partage de mémoire contrôlé entre eux. Les invités sont autorisés à partager certaines de leurs pages avec l'hôte à l'aide d'une hyper-appel, qui demande à l'hyperviseur de remapper ces pages dans la table des pages de l'hôte de l'étape 2. De même, la communication de l'hôte avec TrustZone est rendue possible par des opérations de partage et/ou de prêt de mémoire, toutes étroitement surveillées et contrôlées par pKVM à l'aide de la spécification Firmware Framework for Arm (FF-A).

Étant donné que les exigences de mémoire d'une pVM peuvent changer au fil du temps, une hyper-appel est fournie, ce qui permet de céder la propriété des pages spécifiées appartenant à l'appelant à l'hôte. En pratique, cette hyper-appel est utilisée avec le protocole de ballon virtio pour permettre au VMM de demander à la pVM de lui rendre de la mémoire et à la pVM de signaler au VMM les pages cédées, de manière contrôlée.

L'hyperviseur est chargé de suivre la propriété de toutes les pages de mémoire du système et de savoir si elles sont partagées ou prêtées à d'autres entités. La majeure partie de ce suivi de l'état est effectuée à l'aide de métadonnées associées aux tables de pages de l'hôte et des invités de l'étape 2, à l'aide de bits réservés dans les entrées de table de pages (PTE) qui, comme leur nom l'indique, sont réservés à l'utilisation par logiciel.

L'hôte doit s'assurer qu'il n'essaie pas d'accéder aux pages qui ont été rendues inaccessibles par l'hyperviseur. Un accès hôte illégal entraîne l'injection d'une exception synchrone dans l'hôte par l'hyperviseur, ce qui peut entraîner la réception d'un signal SEGV par la tâche de l'espace utilisateur responsable ou le plantage du noyau hôte. Pour éviter les accès accidentels, le noyau hôte rend les pages données aux invités inéligibles au swap ou à la fusion.

Gestion des interruptions et minuteurs

Les interruptions sont un élément essentiel de la façon dont un invité interagit avec les appareils et de la communication entre les processeurs, où les interruptions interprocesseurs (IPI) sont le principal mécanisme de communication. Le modèle KVM consiste à déléguer toute la gestion des interruptions virtuelles à l'hôte dans EL1, qui se comporte à cette fin comme une partie non approuvée de l'hyperviseur.

pKVM propose une émulation complète du contrôleur d'interruption générique (GICv3) basée sur le code KVM existant. Le minuteur et les IPI sont gérés dans le cadre de ce code d'émulation non approuvé.

Compatibilité avec GICv3

L'interface entre EL1 et EL2 doit s'assurer que l'état d'interruption complet est visible par l'hôte EL1, y compris les copies des registres de l'hyperviseur liées aux interruptions. Cette visibilité est généralement obtenue à l'aide de régions de mémoire partagées, une par processeur virtuel (vCPU).

Le code de compatibilité d'exécution du registre système peut être simplifié pour n'accepter que le piégeage de registre du registre d'interruption généré par logiciel (SGIR) et du registre d'interruption de désactivation (DIR). L'architecture exige que ces registres déclenchent toujours un trap vers EL2, tandis que les autres traps n'ont jusqu'à présent servi qu'à atténuer les erreurs. Tout le reste est géré en matériel.

Côté MMIO, tout est émulé à EL1, en réutilisant toute l'infrastructure actuelle dans KVM. Enfin, Wait for Interrupt (WFI) est toujours relayé vers EL1, car il s'agit de l'une des primitives de planification de base utilisées par KVM.

Compatibilité avec le minuteur

La valeur du comparateur pour le minuteur virtuel doit être exposée à EL1 sur chaque WFI de trappage afin qu'EL1 puisse injecter des interruptions de minuteur lorsque le vCPU est bloqué. Le minuteur physique est entièrement émulé, et tous les pièges sont relayés vers EL1.

Gestion des MMIO

Pour communiquer avec le moniteur de machine virtuelle (VMM) et effectuer l'émulation GIC, les pièges MMIO doivent être relayés vers l'hôte en EL1 pour un tri supplémentaire. pKVM nécessite les éléments suivants:

• IPA et taille de l'accès
• Données en cas d'écriture
• Ordre des octets du processeur au moment du piégeage

De plus, les pièges avec un registre à usage général (GPR) comme source/destination sont relayés à l'aide d'un pseudo-registre de transfert abstrait.

Interfaces invitées

Un invité peut communiquer avec un invité protégé à l'aide d'une combinaison d'hyperappels et d'un accès à la mémoire des régions piégées. Les hyperappels sont exposés conformément à la norme SMCCC, avec une plage réservée à une allocation par le fournisseur par KVM. Les hyperappels suivants sont particulièrement importants pour les invités pKVM.

Hyperappels génériques

• PSCI fournit un mécanisme standard permettant à l'invité de contrôler le cycle de vie de ses vCPU, y compris la mise en ligne, la mise hors service et l'arrêt du système.
• Le TRNG fournit un mécanisme standard permettant à l'invité de demander de l'entropie au pKVM, qui transfère l'appel à EL3. Ce mécanisme est particulièrement utile lorsque l'hôte ne peut pas être autorisé à virtualiser un générateur de nombres aléatoires (RNG) matériel.

Hyperappels pKVM

• Partage de mémoire avec l'hôte. Toute la mémoire invitée est initialement inaccessible à l'hôte, mais l'accès de l'hôte est nécessaire pour la communication en mémoire partagée et pour les appareils paravirtualisés qui s'appuient sur des tampons partagés. Les hyperappels pour partager et annuler le partage de pages avec l'hôte permettent à l'invité de décider exactement quelles parties de la mémoire sont rendues accessibles au reste d'Android sans avoir besoin d'un handshake.
• Renonciation de la mémoire à l'hôte. Toute la mémoire invitée appartient généralement à l'invité jusqu'à sa destruction. Cet état peut être inadapté aux VM de longue durée dont les besoins en mémoire varient au fil du temps. L'hyperappel relinquish permet à un invité de transférer explicitement la propriété des pages à l'hôte sans avoir à le terminer.
• Pièges d'accès à la mémoire sur l'hôte. Traditionnellement, si un invité KVM accède à une adresse qui ne correspond pas à une région de mémoire valide, le thread du vCPU se termine sur l'hôte et l'accès est généralement utilisé pour MMIO et émulé par le VMM dans l'espace utilisateur. Pour faciliter cette gestion, pKVM doit annoncer des informations sur l'instruction défaillante, telles que son adresse, ses paramètres de registre et éventuellement leur contenu à l'hôte, ce qui pourrait exposer involontairement des données sensibles d'un invité protégé si le trap n'était pas prévu. pKVM résout ce problème en considérant ces erreurs comme fatales, sauf si l'invité a précédemment émis une hyper-appel pour identifier la plage d'adresses IPA défaillante comme celle pour laquelle les accès sont autorisés à renvoyer un trap à l'hôte. Cette solution est appelée MMIO guard (protection MMIO).

Appareil d'E/S virtuel (virtio)

Virtio est une norme populaire, portable et mature pour implémenter et interagir avec des appareils paravirtualisés. La plupart des appareils exposés à des invités protégés sont implémentés à l'aide de virtio. Virtio sous-tend également l'implémentation vsock utilisée pour la communication entre un invité protégé et le reste d'Android.

Les appareils virtio sont généralement implémentés dans l'espace utilisateur de l'hôte par le VMM, qui intercepte les accès à la mémoire piégés de l'invité à l'interface MMIO de l'appareil virtio et émule le comportement attendu. L'accès MMIO est relativement coûteux, car chaque accès à l'appareil nécessite un aller-retour vers le VMM et inversement. Par conséquent, la plupart du transfert de données réel entre l'appareil et l'invité se produit à l'aide d'un ensemble de virtqueues en mémoire. Une hypothèse clé de virtio est que l'hôte peut accéder de manière arbitraire à la mémoire invitée. Cette hypothèse est évidente dans la conception de la virtqueue, qui peut contenir des pointeurs vers des tampons dans l'invité auxquels l'émulation de l'appareil est destinée à accéder directement.

Bien que les hyperappels de partage de mémoire décrits précédemment puissent être utilisés pour partager les tampons de données virtio de l'invité à l'hôte, ce partage est nécessairement effectué à la granularité de la page et peut finir par exposer plus de données que nécessaire si la taille du tampon est inférieure à celle d'une page. À la place, l'invité est configuré pour allouer à la fois les virtqueues et leurs tampons de données correspondants à partir d'une fenêtre fixe de mémoire partagée, les données étant copiées (rebondées) vers et depuis la fenêtre selon les besoins.

Interaction avec TrustZone

Bien que les invités ne puissent pas interagir directement avec TrustZone, l'hôte doit toujours pouvoir émettre des appels SMC dans l'environnement sécurisé. Ces appels peuvent spécifier des tampons de mémoire adressés physiquement qui sont inaccessibles à l'hôte. Étant donné que le logiciel sécurisé n'est généralement pas conscient de l'accessibilité du tampon, un hôte malveillant peut utiliser ce tampon pour effectuer une attaque par administrateur confus (analogue à une attaque DMA). Pour éviter de telles attaques, pKVM intercepte tous les appels SMC hôtes vers EL2 et agit en tant que proxy entre l'hôte et le moniteur sécurisé à EL3.

Les appels PSCI de l'hôte sont transférés au micrologiciel EL3 avec des modifications minimales. Plus précisément, le point d'entrée d'un processeur mis en ligne ou repris à partir de la suspension est réécrit afin que la table de pages de l'étape 2 soit installée à EL2 avant de revenir à l'hôte à EL1. Au démarrage, cette protection est appliquée par pKVM.

Cette architecture repose sur le SoC compatible avec PSCI, de préférence en utilisant une version à jour de TF-A comme micrologiciel EL3.

Le Framework de micrologiciel pour Arm (FF-A) standardise les interactions entre les mondes normal et sécurisé, en particulier en présence d'un hyperviseur sécurisé. Une grande partie de la spécification définit un mécanisme de partage de mémoire avec le monde sécurisé, à l'aide d'un format de message commun et d'un modèle d'autorisations bien défini pour les pages sous-jacentes. pKVM met en proxy les messages FF-A pour s'assurer que l'hôte ne tente pas de partager de mémoire avec le côté sécurisé pour lequel il ne dispose pas d'autorisations suffisantes.

Cette architecture repose sur le logiciel du monde sécurisé qui applique le modèle d'accès à la mémoire pour s'assurer que les applications approuvées et tout autre logiciel exécuté dans le monde sécurisé ne peuvent accéder à la mémoire que s'il est détenu exclusivement par le monde sécurisé ou s'il a été explicitement partagé avec lui à l'aide de FF-A. Sur un système avec S-EL2, l'application du modèle d'accès à la mémoire doit être effectuée par un Secure Partition Manager Core (SPMC), tel que Hafnium, qui gère les tables de pages de l'étape 2 pour le monde sécurisé. Sur un système sans S-EL2, le TEE peut appliquer un modèle d'accès à la mémoire via ses tables de pages d'étape 1.

Si l'appel SMC vers EL2 n'est pas un appel PSCI ou un message défini par FF-A, les SMC non gérées sont transférées vers EL3. On suppose que le micrologiciel sécurisé (nécessairement approuvé) peut gérer les SMC non gérées de manière sécurisée, car il comprend les précautions nécessaires pour maintenir l'isolation des pVM.

Moniteur de machine virtuelle

crosvm est un moniteur de machine virtuelle (VMM) qui exécute des machines virtuelles via l'interface KVM de Linux. Ce qui fait la particularité de crosvm est son accent mis sur la sécurité avec l'utilisation du langage de programmation Rust et d'un bac à sable autour des appareils virtuels pour protéger le noyau hôte. Pour en savoir plus sur crosvm, consultez la documentation officielle ici.

Descripteurs de fichiers et ioctls

KVM expose le périphérique de caractères /dev/kvm à l'espace utilisateur avec des ioctls qui constituent l'API KVM. Les ioctls appartiennent aux catégories suivantes:

• Les ioctls système interrogent et définissent des attributs globaux qui affectent l'ensemble du sous-système KVM, et créent des pVM.
• Les ioctls de VM interrogent et définissent des attributs qui créent des processeurs virtuels (vCPU) et des périphériques, et affectent une pVM entière, comme la mise en page de la mémoire et le nombre de processeurs virtuels (vCPU) et de périphériques.
• Les ioctls vCPU interrogent et définissent des attributs qui contrôlent le fonctionnement d'un seul CPU virtuel.
• Les ioctls d'appareils interrogent et définissent des attributs qui contrôlent le fonctionnement d'un seul appareil virtuel.

Chaque processus crosvm exécute exactement une instance de machine virtuelle. Ce processus utilise l'ioctl système KVM_CREATE_VM pour créer un descripteur de fichier de VM pouvant être utilisé pour émettre des ioctls pVM. Un ioctl KVM_CREATE_VCPU ou KVM_CREATE_DEVICE sur un FD de VM crée un vCPU/un appareil et renvoie un descripteur de fichier pointant vers la nouvelle ressource. Les ioctls sur un FD de vCPU ou d'appareil peuvent être utilisés pour contrôler l'appareil créé à l'aide de l'ioctl sur un FD de VM. Pour les vCPU, cela inclut la tâche importante d'exécuter le code invité.

En interne, crosvm enregistre les descripteurs de fichiers de la VM auprès du noyau à l'aide de l'interface epoll déclenchée par une transition de seuil. Le noyau avertit ensuite crosvm chaque fois qu'un nouvel événement est en attente dans l'un des descripteurs de fichiers.

pKVM ajoute une nouvelle fonctionnalité, KVM_CAP_ARM_PROTECTED_VM, qui peut être utilisée pour obtenir des informations sur l'environnement pVM et configurer le mode protégé pour une VM. crosvm l'utilise lors de la création de la pVM si l'indicateur --protected-vm est transmis, pour interroger et réserver la quantité de mémoire appropriée pour le micrologiciel pVM, puis pour activer le mode protégé.

Allocation de mémoire

L'une des principales responsabilités d'un VMM consiste à allouer la mémoire de la VM et à gérer sa mise en page de mémoire. crosvm génère une mise en page de mémoire fixe décrite de manière vague dans le tableau ci-dessous.

FDT en mode normal	PHYS_MEMORY_END - 0x200000
Libérer espace	...
Ramdisk	ALIGN_UP(KERNEL_END, 0x1000000)
Noyau	0x80080000
Bootloader (chargeur d'amorçage)	0x80200000
FDT en mode BIOS	0x80000000
Base de mémoire physique	0x80000000
Micrologiciel pVM	0x7FE00000
Mémoire de l'appareil	0x10000 - 0x40000000

La mémoire physique est allouée avec mmap et la mémoire est donnée à la VM pour remplir ses régions de mémoire, appelées memslots, avec l'ioctl KVM_SET_USER_MEMORY_REGION. Toute la mémoire de la pVM invitée est donc attribuée à l'instance crosvm qui la gère et peut entraîner l'arrêt du processus (arrêt de la VM) si l'hôte commence à manquer de mémoire libre. Lorsqu'une VM est arrêtée, la mémoire est automatiquement effacée par l'hyperviseur et renvoyée au noyau hôte.

Sous KVM standard, le VMM conserve l'accès à toute la mémoire invitée. Avec pKVM, la mémoire invitée n'est pas mappée à l'espace d'adressage physique de l'hôte lorsqu'elle est cédée à l'invité. La seule exception concerne la mémoire explicitement partagée par l'invité, comme pour les appareils virtio.

Les régions MMIO de l'espace d'adressage de l'invité ne sont pas mappées. L'accès de l'invité à ces régions est piégé et entraîne un événement d'E/S sur le FD de la VM. Ce mécanisme est utilisé pour implémenter des appareils virtuels. En mode protégé, l'invité doit confirmer qu'une région de son espace d'adressage est utilisée pour MMIO à l'aide d'une hyper-appel, afin de réduire le risque de fuite d'informations accidentelle.

Planification

Chaque processeur virtuel est représenté par un thread POSIX et planifié par le planificateur Linux hôte. Le thread appelle l'ioctl KVM_RUN sur le FD du vCPU, ce qui entraîne le passage de l'hyperviseur au contexte du vCPU invité. Le planificateur hôte tient compte du temps passé dans un contexte invité en tant que temps utilisé par le thread de vCPU correspondant. KVM_RUN est renvoyé lorsqu'un événement doit être géré par le VMM, comme une E/S, la fin d'une interruption ou l'arrêt du vCPU. Le VMM gère l'événement et appelle à nouveau KVM_RUN.

Pendant KVM_RUN, le thread reste préemptible par le planificateur hôte, sauf pour l'exécution du code de l'hyperviseur EL2, qui n'est pas préemptible. La pVM invitée elle-même ne dispose d'aucun mécanisme permettant de contrôler ce comportement.

Étant donné que tous les threads de vCPU sont planifiés comme n'importe quelle autre tâche d'espace utilisateur, ils sont soumis à tous les mécanismes QoS standards. Plus précisément, chaque thread de vCPU peut être affiné pour les processeurs physiques, placé dans des cpusets, boosté ou plafonné à l'aide d'un forçage de l'utilisation, avoir sa priorité/sa stratégie d'ordonnancement modifiée, etc.

Appareils virtuels

Crosvm est compatible avec un certain nombre d'appareils, y compris les suivants:

• virtio-blk pour les images de disque composites, en mode lecture seule ou lecture-écriture
• vhost-vsock pour la communication avec l'hôte
• virtio-pci en tant que transport virtio
• Horloge temps réel (RTC) pl030
• UART 16550a pour la communication série

Micrologiciel pVM

Le micrologiciel de la pVM (pvmfw) est le premier code exécuté par une pVM, semblable à la ROM de démarrage d'un appareil physique. L'objectif principal de pvmfw est de démarrer le démarrage sécurisé et de dériver le secret unique de la pVM. pvmfw n'est pas limité à une utilisation avec un OS spécifique, tel que Microdroid, tant que l'OS est compatible avec crosvm et qu'il a été correctement signé.

Le binaire pvmfw est stocké dans une partition flash du même nom et est mis à jour à l'aide d'OTA.

Démarrage de l'appareil

La séquence d'étapes suivante est ajoutée à la procédure de démarrage d'un appareil compatible avec pKVM:

1. Le bootloader Android (ABL) charge pvmfw à partir de sa partition dans la mémoire et vérifie l'image.
2. L'ABL obtient ses secrets DICE (Device Identifier Composition Engine) (identifiants d'appareil composés et chaîne de certificats DICE) à partir d'une racine de confiance.
3. L'ABL dérive les CDI nécessaires pour pvmfw et les ajoute au binaire pvmfw.
4. L'ABL ajoute un nœud de région de mémoire réservée linux,pkvm-guest-firmware-memory au DT, décrivant l'emplacement et la taille du binaire pvmfw et les secrets qu'il a dérivés à l'étape précédente.
5. L'ABL cède le contrôle à Linux, qui initialise pKVM.
6. pKVM désassocie la région de mémoire pvmfw des tables de pages d'étape 2 de l'hôte et la protège contre l'hôte (et les invités) pendant toute la durée de disponibilité de l'appareil.

Après le démarrage de l'appareil, Microdroid est démarré conformément aux étapes décrites dans la section Séquence de démarrage du document Microdroid.

Démarrage de la pVM

Lors de la création d'une pVM, crosvm (ou un autre VMM) doit créer un emplacement de mémoire suffisamment grand pour être rempli par l'image pvmfw par l'hyperviseur. Le VMM est également limité dans la liste des registres dont il peut définir la valeur initiale (x0-x14 pour le processeur virtuel principal, aucun pour les processeurs virtuels secondaires). Les autres registres sont réservés et font partie de l'ABI hyperviseur-pvmfw.

Lorsque la pVM est exécutée, l'hyperviseur transmet d'abord le contrôle du vCPU principal à pvmfw. Le micrologiciel s'attend à ce que crosvm ait chargé un kernel signé AVB, qui peut être un bootloader ou toute autre image, et un FDT non signé en mémoire à des décalages connus. pvmfw valide la signature AVB et, en cas de succès, génère un arbre d'appareils approuvé à partir du FDT reçu, efface ses secrets de la mémoire et se branche sur le point d'entrée de la charge utile. Si l'une des étapes de validation échoue, le micrologiciel génère une hyper-appel SYSTEM_RESET PSCI.

Entre les démarrages, les informations sur l'instance de pVM sont stockées dans une partition (appareil virtio-blk) et chiffrées avec le secret de pvmfw pour s'assurer qu'après un redémarrage, le secret est provisionné sur la bonne instance.