启动时验证

对于要启动的 Android 版本中包含的所有可执行代码和数据,启动时验证均要求在使用前以加密形式对其进行验证,其中包括内核(从 boot 分区加载)、设备树(从 dtbo 分区加载)、system 分区和 vendor 分区等。

对于 bootdtbo 这类仅读取一次的小分区,通常是通过将整个内容加载到内存中,然后计算其哈希值来进行验证。接下来,系统会将计算出的哈希值与预期哈希值进行比较。如果值不一致,则 Android 将无法加载。如需了解详情,请参阅启动流程

内存装不下的较大分区(如文件系统)可能会使用哈希树;在这种情况下,验证流程会在将数据加载到内存的过程中持续进行。对于这种情况,系统会在运行时计算哈希树的根哈希值,并将其与预期根哈希值进行比较。Android 包含用于验证较大分区的 dm-verity 驱动程序。如果在某个时刻计算出的根哈希值与预期根哈希值不一致,系统便不会使用相应数据,而且 Android 会进入错误状态。如需了解详情,请参阅 dm-verity 损坏

预期哈希值通常存储在每个经过验证的分区的末尾或开头、专用分区中,或同时存储在以上两个位置。最重要的是,这些哈希值已由信任根以直接或间接的方式签名。举个例子,AVB 实现就支持这两种方式;如需了解详情,请参阅 Android 启动时验证

回滚保护

即使更新流程完全安全,攻击者仍可能会利用非永久性 Android 内核漏洞来手动安装更易受攻击的旧版 Android 系统,重新启动进入易受攻击的版本,然后通过该 Android 版本来安装永久性漏洞。在这种情况下,攻击者可通过这种漏洞永久拥有相应设备,并可以执行任何操作(包括停用更新)。

防范这类攻击的保护措施称为“回滚保护”。“回滚保护”通常通过以下方式实现:使用防篡改的存储空间来记录最新的 Android 版本,并在 Android 版本低于记录的版本时拒绝启动 Android。系统通常会针对每个分区来跟踪版本。

如需详细了解 AVB 处理回滚保护的方式,请参阅 AVB README

处理验证错误

验证在启动时(例如,如果在 boot 分区上计算出的哈希值与预期哈希值不一致)或运行时(例如,如果 dm-verity 在 system 分区上遇到验证错误)都可能会失败。如果验证在启动时失败,设备则无法启动,而且最终用户需要执行相关步骤才能恢复设备。

如果验证在运行时失败,恢复流程就会更复杂一些。如果设备使用的是 dm-verity,则应在 restart 模式下进行配置。在 restart 模式下,如果遇到验证错误,设备会立即重启,并设置特定标记以表明错误原因。引导加载程序应该会注意到该标记,并将 dm-verity 切换为使用 I/O 错误 (eio) 模式并保持该模式,直到安装新的更新为止。

eio 模式下启动时,设备会显示错误屏幕,以通知用户系统已检测到损坏,而且设备可能无法正常使用。该屏幕会持续显示,直到用户将其关闭为止。在 eio 模式下,如果遇到验证错误,dm-verity 驱动程序将不会重启设备,而是返回 EIO 错误,并且相应的应用需要处理该错误。

这样做的目的是,让系统更新程序能够正常运行(以便安装不含损坏错误的新操作系统),或者让用户能够从设备中取出尽可能多的数据。安装新的操作系统后,引导加载程序会注意到新安装的操作系统,并切换回 restart 模式。