Les appareils informatiques mobiles traitent des quantités de plus en plus importantes de données personnelles sensibles. La présence de ces données sensibles, aidée par la connexion constante avec le monde extérieur, a entraîné une augmentation des investissements de la part d'acteurs malveillants intéressés à exploiter les vulnérabilités pour atteindre leurs objectifs.
Les systèmes d'exploitation, avec l'aide d'unités de gestion de la mémoire matérielle (MMU), fournissent des abstractions qui permettent d'isoler les processus non liés les uns des autres. Seuls les composants faisant partie du TCB sont autorisés à programmer directement ces MMU.
Ce modèle a été à la base de 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 dans la mesure où la TCB actuelle est trop volumineuse : elle inclut la plupart des pilotes de périphériques et de bus, des planificateurs complexes, des systèmes de fichiers, des piles et protocoles réseau, des caches, des analyseurs et chargeurs exécutables et des sockets. Il est devenu très difficile de garantir la sécurité de chaque recoin de ce système complexe.
Le noyau Linux compte plus de 20 millions de lignes de code et le taux de modifications et de réécritures est étonnant. Cette croissance est une immense aide pour Android et notre écosystème. Cependant son grand TCB rend difficile de garantir l'absence de vulnérabilités exploitables.
Les fournisseurs de matériel ont développé des solutions, telles que Arm's TrustZone, qui permettent aux processeurs de fonctionner en mode sécurisé et de marquer 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 directement accessibles au monde sécurisé, qui fournit des services au monde non sécurisé à la demande.
La principale limitation de ce type de solutions est que les domaines sont trop grossiers : uniquement sécurisés et non sécurisés. Au fur et à mesure que de plus en plus de cas d'utilisation nécessitant une isolation du système d'exploitation sont introduits, la surface d'attaque augmente et les vulnérabilités risquent de compromettre l'ensemble de l'appareil.
Une autre limitation des solutions actuelles est qu'elles sont conçues pour un monde relativement statique dans lequel toutes les ressources des cas d'utilisation sont comptabilisées et allouées à l'avance. Ces solutions ne sont pas assez bonnes pour les cas d'utilisation dynamiques 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 fondamentaux comme Keymint et Gatekeeper.
Pour remédier à ces limitations 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 le nom d'Android Virtualization Framework (AVF).
L'objectif principal d'AVF est de fournir un environnement d'exécution sécurisé et privé pour les cas d'utilisation de nouvelle génération.