Les appareils mobiles gèrent de plus en plus de données sensibles à caractère personnel. La présence de ces données sensibles, favorisée par la connexion permanente au monde extérieur, a entraîné une augmentation des investissements de la part d'acteurs malveillants cherchant à exploiter les failles pour atteindre leurs objectifs.
Les systèmes d'exploitation, à l'aide d'unités de gestion de la mémoire (MMU) matérielles, fournissent des abstractions qui isolent les processus sans rapport les uns des autres. Seuls les composants qui font partie de la base de calcul sécurisée (TCB) sont autorisés à programmer directement ces MMU.
Ce modèle a servi de base à la mise en œuvre de la confidentialité et de la sécurité depuis l'introduction des systèmes d'exploitation de type Unix. Cependant, cette exigence est devenue problématique, car le TCB d'aujourd'hui est trop volumineux: il inclut la plupart des pilotes d'appareils et de bus, des planificateurs complexes, des systèmes de fichiers, des piles et des protocoles réseau, des caches, des analyseurs et des chargeurs d'exécutables, ainsi que des sockets. Il est devenu très difficile de s'assurer que chaque recoin de ce système complexe est sécurisé.
Le noyau Linux compte plus de 20 millions de lignes de code, et le taux de modifications et de réécritures est stupéfiant. Cette croissance apporte une aide considérable à Android et à notre écosystème. Cependant, sa grande TCB rend difficile la garantie de l'absence de failles exploitables.
Les fournisseurs de matériel ont développé des solutions, telles que TrustZone d'Arm, qui permettent aux processeurs de s'exécuter en mode sécurisé et de taguer les transactions de mémoire comme "sécurisées" ou "non sécurisées". Dans de tels systèmes, les données sensibles sont stockées et uniquement disponibles directement pour l'environnement sécurisé, qui fournit des services à l'environnement non sécurisé à la demande.
La principale limite de ce type de solutions est que les domaines sont trop grossiers: sécurisés et non sécurisés uniquement. À mesure que de nouveaux cas d'utilisation nécessitant une isolation du système d'exploitation sont introduits, la surface d'attaque augmente et les failles sont susceptibles de compromettre l'ensemble de l'appareil.
Une autre limite des solutions actuelles est qu'elles sont conçues pour un monde relativement statique dans lequel tous les cas d'utilisation sont pris en compte et alloués à l'avance. Ces solutions ne sont pas suffisantes pour les cas d'utilisation dynamique dans lesquels les ressources sont allouées à la demande.
De plus, les API utilisées en dehors du système d'exploitation Android sont fragmentées et limitent notre capacité à déployer des cas d'utilisation à l'échelle d'Android, y compris des éléments fondamentaux tels que Keymint et Gatekeeper.
Pour répondre à ces limites et permettre à Android de fournir une base solide pour les cas d'utilisation de nouvelle génération, Android 13 introduit la virtualisation sécurisée sous la forme du framework de virtualisation Android (AVF).
L'objectif principal de l'AVF est de fournir un environnement d'exécution sécurisé et privé pour les cas d'utilisation de nouvelle génération.