Les appareils mobiles traitent des quantités de plus en plus importantes de données à caractère personnel 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 des acteurs malveillants intéressés par l'exploitation des failles pour atteindre leurs objectifs.
Les systèmes d'exploitation, avec l'aide des unités de gestion de la mémoire (MMU) matérielles, 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 sécurisée (TCB) sont autorisés à programmer directement ces MMU.
Ce modèle a servi de base à l'implémentation 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 le TCB actuel est trop volumineux : il 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 garantir la sécurité de chaque recoin de ce système complexe.
Le noyau Linux comporte plus de 20 millions de lignes de code, et le rythme des modifications et des réécritures est stupéfiant. Cette croissance est d'une aide précieuse pour Android et notre écosystème. Toutefois, son grand 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'identifier les transactions 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 celui-ci, 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 généraux (uniquement sécurisés et non sécurisés). À 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 toutes les ressources de cas d'utilisation sont comptabilisées et allouées à l'avance. Ces solutions ne sont pas adaptées aux 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 comme 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 que framework de virtualisation Android (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.