8、Bootloader安全机制：Verified Boot、AVB、dm-verity原理、SELinux在启动过程中的作用
说到Android的安全性，很多人第一反应是应用沙箱、权限管理这些。但我要说，真正的安全防线，其实从你按下电源键的那一刻就开始了。
Bootloader是整个系统的第一个信任锚点。如果它被攻破了，后面所有的安全措施都是白搭。我当年在调试一款设备时，就遇到过Bootloader被篡改导致系统无法启动的案例——嗯，从那以后我对这块的重视程度直接拉满。
8.1 为什么需要Verified Boot？
你想想看，手机从关机到进入桌面，中间经历了多少步？Bootloader加载内核，内核挂载根文件系统，init进程启动，各种服务跑起来……这中间任何一个环节被植入恶意代码，整个系统就沦陷了。
Verified Boot要解决的核心问题就是：如何确保你正在启动的系统，是厂商签过名的、没有被篡改过的系统。
说白了，它是一条信任链。从硬件开始，一级验证一级，直到整个系统完全启动。
信任链的核心逻辑：
硬件不可变信任根 → Bootloader验证Boot分区 → Boot分区验证System分区 → System分区验证其他分区
每一级都只信任上一级签过名的内容，环环相扣。
8.2 AVB（Android Verified Boot）到底是什么？
AVB是Google在Android 8.0之后主推的验证启动方案。它比早期的Verified Boot更完善，也更灵活。
我记得第一次接触AVB时，最让我印象深刻的是它的哈希树（Hash Tree）设计。传统的验证方式是把整个分区做个哈希，然后签名。但这样做有个问题——分区越大，验证越慢。一个4GB的system分区，全量哈希可能要好几秒。
AVB的做法是：把分区切成4KB的块，每块算一个哈希，然后把这些哈希再组成一棵树。验证的时候，只需要验证你实际读取的那些块，而不是整个分区。
个人经验：我在做OTA升级验证时，发现AVB的哈希树设计对增量更新特别友好。只更新了哪些块，就只验证那些块，效率比全量验证高了一个数量级。
AVB的另一个亮点是vbmeta分区。这个分区很小，但它是整个验证链的"总开关"。里面包含了所有分区的哈希值和签名信息。Bootloader只需要验证vbmeta的签名，就能信任所有分区。
AVB支持三种模式：
- 绿色模式（验证通过）：正常启动，显示"您的设备已通过验证"
- 黄色模式（警告）：验证失败但允许启动，显示警告信息
- 红色模式（禁止）：验证失败且不允许启动，直接停在Bootloader
这三种模式的设计，其实是为了平衡安全性和可用性。我见过一些厂商为了省事，直接把黄色模式关了——设备验证失败就直接变砖。这种做法我个人不太认同，毕竟用户有时候只是刷了个第三方内核，不一定是有恶意。
8.3 dm-verity：内核层的块设备验证
AVB负责的是启动阶段的验证，那系统跑起来之后呢？恶意软件能不能在运行时修改系统文件？
这就是dm-verity登场的地方。
dm-verity是Linux内核的一个设备映射器（Device Mapper）目标。它做的事情很简单：每次读取块设备时，都验证这个块是否和哈希树中的值一致。
它的工作流程是这样的：
- 系统启动时，内核通过AVB获取到system分区的哈希树根哈希
- dm-verity在system分区之上创建一个只读的映射层
- 每次应用读取/system下的文件时，内核实际上是从dm-verity映射层读取
- dm-verity会验证每个读取的块，如果哈希不匹配，返回I/O错误
# dm-verity在内核中的配置示例
# 这是我在调试dm-verity时常用的参数
veritysetup create system_verity /dev/block/mmcblk0p23 /dev/block/mmcblk0p24 \
--hash-offset=0 \
--data-block-size=4096 \
--hash-block-size=4096 \
--salt=your_salt_here \
--root-hash=your_root_hash_here注意：dm-verity的验证是"按需"的。如果你不读取某个块，它就不会验证。这意味着恶意软件如果只是把恶意代码写到了system分区但不去读它，dm-verity是检测不到的。不过没关系——因为系统启动时已经验证过整个分区的完整性了，运行时恶意软件想修改system分区？抱歉，dm-verity映射层是只读的。
dm-verity还有一个"宽容模式"（I/O错误时继续运行）和"严格模式"（I/O错误时panic）。我建议生产环境用严格模式，开发调试时可以用宽容模式——我曾经因为忘了切换模式，调试了整整两天才发现是dm-verity在"捣乱"。
8.4 SELinux在启动过程中的作用
聊完dm-verity，我们来说说SELinux。很多人觉得SELinux是系统跑起来之后才生效的，其实不然——它在启动过程中就已经开始发挥作用了。
SELinux在启动过程中的角色，我总结为三点：
- 加载安全策略：init进程在启动早期就会加载SELinux策略文件（sepolicy），这个文件决定了哪些进程能访问哪些资源
- 初始化安全上下文：每个文件、每个进程都需要被赋予正确的安全上下文（security context），否则系统无法正常运行
- 限制早期进程：在系统完全启动前，一些关键进程（如ueventd、logd）就已经在SELinux的管控下了
我记得有一次，我在移植Android到新平台时，遇到了一个诡异的问题：系统启动到一半就卡住了。折腾了两天，最后发现是SELinux策略文件没有正确加载，导致init进程无法访问设备节点。
启动过程中的SELinux关键节点：
| 启动阶段 | SELinux动作 | 说明 |
|---|---|---|
| 内核启动 | 初始化SELinux子系统 | 内核编译时需要开启CONFIG_SECURITY_SELINUX |
| init第一阶段 | 加载sepolicy文件 | 从ramdisk中读取，设置 enforcing/permissive 模式 |
| init第二阶段 | 初始化文件安全上下文 | 使用file_contexts文件为所有文件打标签 |
| 服务启动 | 应用进程安全策略 | 每个服务在启动时被赋予对应的domain |
这里有个容易踩的坑：sepolicy文件本身也需要被验证。如果攻击者替换了sepolicy文件，那SELinux就形同虚设了。所以sepolicy文件通常放在system分区，由dm-verity保护。或者放在ramdisk中，由Bootloader验证。
我个人习惯在开发阶段把SELinux设为permissive模式，这样能看到所有的违规日志，但不会阻止操作。等调试差不多了，再切回enforcing模式。不过要提醒你——千万别忘了切回来，我见过有人带着permissive模式就发布了……
8.5 三者如何协同工作？
AVB、dm-verity、SELinux这三者不是孤立的，它们构成了一个完整的安全体系：
- AVB：负责启动阶段的完整性验证，确保你加载的内核和系统镜像是可信的
- dm-verity：负责运行时的完整性保护，防止系统文件被篡改
- SELinux：负责访问控制，即使系统文件是完整的，也要限制进程的行为
打个比方：AVB是门卫，检查进门的人是不是本人；dm-verity是监控摄像头，盯着屋里的人别乱动东西；SELinux是规章制度，告诉你什么东西能碰、什么东西不能碰。
缺了任何一个，安全防线都有漏洞。
避坑指南：我曾经在调试一个设备时，发现AVB验证通过了，dm-verity也正常，但系统就是报安全异常。查了很久才发现，是SELinux策略中漏掉了一个domain的声明，导致某个系统服务在启动时被拒绝访问关键文件。所以，这三个环节的日志都要看，别只盯着一个。
最后说一句：安全没有银弹。AVB、dm-verity、SELinux这套组合拳虽然强大，但也需要正确的配置和持续的维护。我见过不少设备，虽然硬件上支持这些安全特性，但因为厂商配置不当，导致安全防线形同虚设。所以，理解原理只是第一步，真正落地才是考验。