1. 设计目标与作用层级
| 特性 | dm-verity | fs-verity |
|---|
| 作用对象 | 块设备（如 /dev/block/sda1） | 单个文件（如 /system/app/App.apk） |
| 验证粒度 | 按数据块（默认 4KB）逐块验证 | 按文件数据块（如 4KB）逐块验证 |
| 实现层级 | 设备映射层（Device Mapper） | 文件系统层（如 ext4、f2fs） |
| 典型用途 | 系统分区完整性保护（如 Android /system） | 单个文件防篡改（如 APK、配置文件） |
2. 技术实现差异
| 技术点 | dm-verity | fs-verity |
|---|
| 哈希树结构 | 全分区哈希树（从数据块到根哈希） | 单文件哈希树（仅文件内容生成哈希树） |
| 元数据存储 | 单独存储在分区末尾或指定位置 | 嵌入文件扩展属性（xattr）或专用文件元数据 |
| 验证触发时机 | 块设备读取时实时验证 | 文件打开时验证元数据，读取时按需验证数据块 |
| 只读模式 | 强制只读（无法修改已挂载设备） | 文件可写，但启用后自动变为只读 |
3. 应用场景对比
| 场景 | dm-verity | fs-verity |
|---|
| 系统完整性保护 | Android 系统分区、只读固件分区 | 容器镜像、敏感配置文件、可执行文件 |
| 恶意篡改防御 | 防止 rootkit 修改系统核心文件 | 防止 APK 被注入恶意代码 |
| 性能影响 | 全分区验证，启动时延迟较高 | 按需验证，首次打开文件时计算哈希树（一次性） |
| 典型部署案例 | Android Verified Boot (AVB) | Google Play 应用签名验证、Linux 安全容器 |
4. 配置与使用
| 操作 | dm-verity | fs-verity |
|---|
| 启用工具 | veritysetup（用户空间） | fsverity（文件系统工具） |
| 哈希树生成 | 需要预先计算并写入分区 | 动态生成（fsverity enable 后自动追加） |
| 签名支持 | 支持根哈希签名（需集成到启动链） | 支持文件级签名（签名存储在文件元数据） |
| 兼容性 | 任意文件系统（基于块设备） | 需文件系统支持（ext4、f2fs、btrfs 等） |
5. 安全性对比
| 安全特性 | dm-verity | fs-verity |
|---|
| 抗物理攻击 | 依赖硬件级信任链（如 Secure Boot） | 依赖文件系统元数据完整性 |
| 防御范围 | 全分区保护（包括未使用空间） | 仅保护文件内容，不保护文件元数据（如时间戳） |
| 恢复能力 | 无（验证失败则拒绝访问） | 可搭配 FEC（前向纠错）修复损坏文件 |
6. 性能开销（示例数据）
| 场景 | dm-verity (IOPS) | fs-verity (IOPS) |
|---|
| 连续读（未验证） | ~100,000 | ~120,000 |
| 连续读（启用验证） | ~75,000（下降 25%） | ~115,000（下降 4%） |
| 首次加载延迟 | 启动时 500ms~2s | 文件首次打开 +50ms |
总结
- dm-verity 是“全分区装甲”，适合 强制保护系统核心分区
- fs-verity 是“文件级指纹锁”，适合 精细化保护关键文件
两者可组合使用：用 dm-verity 保护系统分区，再用 fs-verity 保护分区内的敏感文件，形成双层防御。
