为什么选择 AVF?

移动计算设备处理的个人敏感数据的数量日益增加。这类敏感数据的存在,再加上经常与外界保持联络,有意利用漏洞进一步实现其目标的恶意攻击者更是加大力度搞破坏。

操作系统借助硬件内存管理单元 (MMU) 提供抽象化功能,以便让不相关的进程彼此隔离。只有 TCB 中包含的组件才能直接对这些 MMU 进行编程。

自推出类似 Unix 的操作系统以来,该模型一直是实现隐私保护和安全机制的基础。然而,如今的 TCB 过大,上述要求已很难满足:它包含大多数设备和总线驱动程序、复杂的调度程序、文件系统、网络堆栈和协议、缓存、可执行解析器和加载器以及套接字。确保这个复杂系统的方方面面都安全变得非常困难。

Linux 内核中有超过 2000 万行代码,更改和重写的速度令人惊讶。这一发展对 Android 和我们的生态系统而言具有极大的帮助。但是,其较大的 TCB 使得确保不存在可利用的漏洞很困难。

硬件供应商开发了一些解决方案,例如 Arm 的 TrustZone。它允许处理器在安全模式下运行,并将内存事务标记为“安全”或“非安全”。在此类系统中,敏感数据会存储在安全环境中,并且仅直接提供给安全环境,这类安全环境会按需向非安全环境提供服务。

此类解决方案的主要限制是情况分类过于粗略,仅分为安全和非安全。随着越来越多需要与操作系统隔离的用例的引入,攻击面越来越多,漏洞可能导致整个设备遭受破坏。

如今的解决方案的另一个限制是,其设计主要面向相对静态的环境,其中所有用例资源都有迹可循,并且提前分配。这些解决方案对于按需分配资源的动态用例不够友好。

此外,在 Android 操作系统以外使用的 API 比较分散,限制了我们在 Android 级别部署用例的能力,包括 Keymint 和 Gatekeeper 等基础组件。

为了解决这些限制并让 Android 为下一代用例提供强大的基础,Android 13 引入了安全的虚拟化,即 Android 虚拟化框架 (AVF)。

AVF 的主要目标是为下一代用例提供安全、私密的执行环境。