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, associée à la connexion constante au monde extérieur, a entraîné une augmentation des investissements de la part d'acteurs malveillants intéressés par l'exploitation des failles pour atteindre leurs objectifs.
Les systèmes d'exploitation, à l'aide d'unités de gestion de la mémoire matérielle (MMU), fournissent des abstractions qui isolent les processus non liés les uns des autres. Seuls les composants qui font partie de la base de calcul de confiance (TCB) sont autorisés à programmer directement ces MMU.
Ce modèle est à 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. Toutefois, cette exigence est devenue problématique, car 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, une pile et des protocoles réseau, des caches, des analyseurs et des chargeurs 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 comporte plus de 20 millions de lignes de code, et le taux de modifications et de réécritures est étonnant. Cette croissance est d'une aide précieuse pour Android et notre écosystème. Toutefois, sa grande TCB rend difficile de garantir 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 d'étiqueter les transactions de mémoire comme "sécurisées" ou "non sécurisées". Dans ces systèmes, les données sensibles sont stockées dans le monde sécurisé et ne sont directement disponibles que pour lui, qui fournit des services au monde non sécurisé à la demande.
La principale limite de ce type de solutions est que les domaines sont trop grossiers : uniquement sécurisés et non sécurisés. À mesure que davantage de 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 toutes les ressources de cas d'utilisation sont comptabilisées et allouées à l'avance. Ces solutions ne sont pas assez efficaces 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 éléments fondamentaux tels que Keymint et Gatekeeper.
Pour résoudre 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 en tant qu'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.