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，是设计使然。别想着绕过，得接受它对只读性的绝对要求。
