Linux dm-verity 的 Merkle tree 与只读根文件系统完整性保护

dm-verity的merkle tree以文件系统块（如4kb）为叶子节点，逐层哈希构建，树根哈希硬编码于启动参数；验证时每次读块实时计算路径哈希并与预存值比对，不匹配则返回eio。

dm-verity 的 Merkle tree 是怎么生成和验证的

dm-verity 不是靠扫描整个 rootfs 来校验，而是把文件系统块（通常是 4KB）当作叶子节点，逐层哈希向上构造 Merkle tree。树根哈希（root hash）被硬编码进内核启动参数或 initramfs 里，启动时由 device-mapper 驱动加载并验证每个读取的块。

关键点在于：树结构完全由数据块大小、设备总大小和哈希算法决定，不依赖文件路径或元数据——所以它只保护“块内容”，不管文件是否被删、重命名或新增。

• hash_algorithm 默认是 sha256，但某些旧内核不支持 sha512，换算法前得查 cat /proc/crypto | grep sha
• 叶子层块大小（data_block_size）必须和实际文件系统逻辑块对齐，常见为 4096；设错会导致 device-mapper: verity: invalid hash block size
• 树高由设备大小自动推导，不能手动指定；生成工具 veritysetup 会报出 tree_depth，调试时可用来反推验证路径是否合理

构建只读 rootfs 时，verity 表如何写进 device-mapper

不是直接挂载分区，而是用 dmsetup create 把原始设备映射成一个带校验的逻辑设备（比如 /dev/mapper/verity-root），再把这个设备作为 rootfs 挂载点。这个过程必须在 initramfs 里完成，且不能晚于 switch_root。

典型映射表格式：0 <device_size> verity <version><data_device><hash_device><data_block_size><hash_block_size><num_data_blocks><hash_start_block><root_hash><salt></salt></root_hash></hash_start_block></num_data_blocks></hash_block_size></data_block_size></hash_device></data_device></version></device_size>，其中 hash_device 可以和 data_device 是同一块设备（hash 放在末尾），也可以是独立分区。

• 如果 hash_device 和 data_device 同盘，hash_start_block 必须严格等于 num_data_blocks，否则验证时读越界，内核报 bio too big device
• root_hash 必须是十六进制字符串（无 0x 前缀），长度取决于哈希算法：sha256 是 64 字符，少一位就会触发 Invalid root hash Length
• initramfs 里执行 dmsetup create 前，要确保 dm-verity 模块已加载（modprobe dm_verity），否则 Unknown table target type 'verity'

为什么改了文件系统内容后，verity 校验就失败

因为 dm-verity 在每次读块时实时计算该块的 Merkle 路径哈希，并与预存的树中对应节点比对。只要任意一个数据块内容变化（哪怕只是 touch 一个空文件），从叶子到根的整条路径哈希全变，最终 root hash 对不上，驱动直接返回 EIO，上层表现为 “Read-only file system” 或 “input/output Error”。

• 这种失败是静默且不可绕过的——你无法在运行时 disable verity，也不能临时 remount rw；唯一办法是重新生成 hash tree 并更新 root hash
• 注意：ext4 的 journal、TRIM、discard 等操作本身不改数据块内容，不会触发失败；但 e2fsck -f 或 resize2fs 可能重排块，必须重新生成 verity 表
• 调试时可用 dmsetup table --showkeys 查看当前加载的 root hash，对比生成时保存的值，确认是否被意外篡改

initramfs 里验证失败，常见日志怎么看

内核 log（dmesg）里最相关的几行通常带 dm-verity 和 block 关键字，不是所有错误都明确说 “hash mismatch”。真正有效的线索藏在 bio 层和 device-mapper 日志里。

• 看到 device-mapper: verity: checksum failed —— 确认 root hash 或 salt 错了，或者设备被写过
• 看到 end_request: I/O error, dev dm-0, sector XXXXX + Buffer I/O error on dev dm-0 —— 很可能是某一层哈希块读取失败（比如 hash 区域损坏或 offset 错）
• 看到 device-mapper: verity: invalid hash device —— 多半是 hash_device 设成了只读 loop 设备但没用 --read-only 参数创建

verity 的难点不在配置，而在它把“数据一致性”提前到块设备层，一旦部署，任何底层变更都会立刻暴露——这不是 bug，是设计使然。别想着绕过，得接受它对只读性的绝对要求。