安全启动：从硬件到内核的信任链
安全启动这个话题，说白了就是回答一个问题：你怎么知道你手机里跑的系统，真的是你想要的系统？
我刚开始接触Android安全时，觉得这玩意儿离应用开发很远。直到有一次，我在调试一台刷机失败的设备，发现系统启动到一半就挂了。后来一查，是boot分区被篡改过，dm-verity检测到数据不一致，直接拒绝挂载。嗯，从那以后，我再也不敢小看安全启动这套机制了。
Verified Boot的核心思想
Verified Boot，验证启动，它的逻辑其实很简单——建立一条从硬件到内核的信任链。
你想想看，手机开机时，最先跑的是BootROM，这是固化在芯片里的代码，改不了。BootROM去校验Bootloader，Bootloader去校验Boot分区，Boot分区再去校验System分区。每一级都验证下一级的签名，只要有一环断了，启动就失败。
信任链传递：
- BootROM（硬件不可变）→ 校验Bootloader签名
- Bootloader → 校验Boot分区（包含kernel和ramdisk）
- Boot分区 → 校验System分区（通过dm-verity）
- System分区 → 校验Vendor分区、OEM分区等
我在项目中遇到过一台设备，客户说刷了官方固件但启动不了。查了半天，发现是Bootloader版本太旧，不认识新固件的签名算法。这就是信任链断裂的典型例子——每一级都得匹配，少一个都不行。
dm-verity：块级别的完整性校验
dm-verity是Device Mapper的一个模块，它做的事情很纯粹：在块设备层面，对每个数据块做哈希校验。
它的工作方式是这样的：
- 系统编译时，对整个System分区计算哈希树（hash tree）
- 哈希树的根哈希值被签名，存放在vbmeta分区
- 启动时，内核通过dm-verity挂载System分区
- 每次读取数据块，都会验证其哈希值是否匹配
说白了，dm-verity就像给每个数据块贴了个防伪标签。你读数据时，它先撕开标签看看是不是真的。假的？直接报I/O错误。
我个人习惯：在调试dm-verity问题时，先检查vbmeta分区是否完整。很多启动失败的原因，其实就是vbmeta被刷坏了或者签名不匹配。
dm-verity与SELinux的结合
这里有个有意思的点：dm-verity只管数据完整性，它不管谁在访问这些数据。而SELinux管的是访问控制，它不管数据是不是被篡改过。两者结合，才构成完整的安全防护。
我举个例子：
- dm-verity保证System分区里的文件没有被篡改
- SELinux保证只有授权的进程才能访问这些文件
- 两者配合，既防篡改，又防越权
在Android系统中，这个结合体现在启动阶段：
// init.rc中的典型配置
on fs
mount_all /vendor/etc/fstab.${ro.hardware}
// fstab中的dm-verity配置示例
/dev/block/by-name/system /system ext4 ro,barrier=1,discard wait,verify,avb=/dev/block/by-name/vbmeta注意那个verify标志，它告诉内核：这个分区要用dm-verity校验。而avb参数指定了vbmeta分区的位置，里面存着签名信息。
我曾经踩过一个坑：在定制系统时，修改了fstab但忘了更新vbmeta的哈希树。结果启动时dm-verity检测到数据不一致，直接进入恢复模式。后来我养成了习惯：每次修改系统分区内容，必须重新生成vbmeta。
启动完整性校验的完整流程
来，我画个图帮你理清整个流程：
这个图展示了完整的信任链。每一级都在验证下一级的完整性，而SELinux则在系统运行后持续提供访问控制。
实际项目中的注意事项
我在做系统定制时，总结了几条经验：
| 场景 | 问题 | 解决方案 |
|---|---|---|
| 修改系统分区内容 | dm-verity校验失败 | 重新生成vbmeta并签名 |
| 关闭dm-verity调试 | 内核启动参数需修改 | 在boot.img的cmdline中添加androidboot.veritymode=enforcing |
| SELinux策略冲突 | 服务无法访问系统文件 | 检查avc log，添加对应allow规则 |
| OTA升级后启动失败 | vbmeta与系统版本不匹配 | 确保OTA包中包含正确的vbmeta |
特别注意：在生产环境中，千万不要为了调试方便而关闭dm-verity。我曾经见过有人把androidboot.veritymode=disabled写死在kernel cmdline里，结果设备被植入恶意软件都没发现。安全启动这道防线，一旦开了口子，后面就全完了。
总结一下
安全启动不是单一的技术，而是一套组合拳：
- Verified Boot建立信任链，从硬件到内核逐级验证
- dm-verity在块级别保证数据完整性
- SELinux在运行时控制访问权限
- 三者结合，才能构建真正可信的Android系统
嗯，这套机制虽然复杂，但它是Android安全的基础。你想想看，如果没有安全启动，随便一个恶意软件就能替换系统文件，那手机还有什么安全性可言？
我个人建议，在做系统定制时，先把这套流程跑通。哪怕只是在自己的开发板上，也要体验一下从签名到校验的完整过程。只有亲手踩过坑，才能真正理解安全启动的价值。
公众号:蓝海资料掘金营，微信deep3321