Mobile computing devices are handling increasingly larger amounts of personally sensitive data. The presence of such sensitive data, aided by the constant connection to the outside world, has resulted in increased investments from malicious actors interested in exploiting vulnerabilities to further their goals.
Operating systems, with the help of hardware memory management units (MMUs), provide abstractions that isolate unrelated processes from each other. Only components that are part of the Trusted Computing Base (TCB) are allowed to directly program these MMUs.
This model has been the foundation of how privacy and security have been implemented since the introduction of Unix-like operating systems. However, this requirement has become problematic in that today’s TCB is too large: it includes most device and bus drivers, complex schedulers, file systems, network stack and protocols, caches, executable parsers and loaders, and sockets. It has become very difficult to ensure every corner of this complicated system is safe.
The Linux kernel has over 20 million lines of code and the rate of changes and rewrites is astonishing. This growth is an immense help to Android and our ecosystem. However its large TCB makes it difficult to ensure the absence of exploitable vulnerabilities.
Hardware vendors have developed solutions, such as Arm’s TrustZone, which allow processors to run in Secure mode and tag memory transactions as "secure" or "nonsecure." In such systems, sensitive data is stored in and only directly available to the secure world, which provides services to the nonsecure world on demand.
The main limitation of these kind of solutions is that the domains are too coarse-grained: only secure and nonsecure. As more use cases that require isolation from the operating system are introduced, the attack surface increases and vulnerabilities are likely to lead to compromise of the entire device.
Another limitation of today’s solutions is that they're designed for a relatively static world in which all use case resources are accounted for and allocated ahead of time. These solutions aren't good enough for dynamic use cases in which resources are allocated on demand.
In addition, the APIs used outside of the Android operating system are fragmented and restrict our ability to deploy use cases at the Android scale, including fundamentals like Keymint and Gatekeeper.
To address these limitations and enable Android to provide a robust foundation for next generation use cases, Android 13 introduces secure virtualization as the Android Virtualization Framework (AVF).
The main goal of AVF is to provide a secure and private execution environment for next-generation use cases.