[背景]
我正在开发一个嵌入式 Linux 平台，尝试在 NAND 闪存上设置 dm-verity。我正在使用 cryptsetup v2.3.0（soc 供应商包的一部分），这是我第一次尝试。我veritysetup已经成功创建了哈希树并验证了它；其中我的 data_device 是一个 mtdblock，它引用根文件系统分区（例如 /dev/mtdblock8），而我的 hash_device 指向另一个分区的安装路径上的文件路径。但是，此分区尚未安装，文件直到启动序列后期才可用，因此我正在努力将哈希树数据直接存储到内存块设备，以便在启动验证期间可以访问它。
我尝试过使用相同的mtdblock 作为 data_device，但提供使用数据块数量计算得出的哈希偏移量以验证 * 数据块大小。我尝试使用 mtdblock 作为 hash_device，该设备当前用于另一个分区的文件（有或没有偏移量）。最后我尝试使用一个空的 mtdblock 作为我的 hash_device。这只是一个随机的“剩余”原始分区，与任何内容都没有关联。我更喜欢使用这个空块，因为它浪费了大约 2MB 的空间，并且可以用于此目的。
[问题]
在最简单的形式中，我的命令类似于：veritysetup -v --debug format /dev/mtdblock8 /dev/mtdblockX其中 X 是某个数字。每次，我都会收到通用 I/O 错误，并且 --debug 日志显示“无法将摘要写入哈希设备”。这对应于 verity_hash.c 文件中失败的 fwrite密码设置。使用测试程序，我发现我无法直接写入/dev/mtdblockX，但可以直接写入/dev/mtdX（字符设备与 mtdblock 关联）。但，向 veritysetup 提供字符设备会导致失败！该工具不接受字符设备，它会失败并显示不兼容的设备错误消息，并且在代码中，唯一接受的设备类型是块设备和常规文件：
if (fstat(devfd, &st) < 0)
r = -EINVAL;
else if (!S_ISBLK(st.st_mode))
r = S_ISREG(st.st_mode) ? -ENOTBLK : -EINVAL;
if (r == -EINVAL) {
log_err(cd, _("Device %s is not compatible."),
device_path(device));
close(devfd);
return r;
}
我考虑修改代码并为我的平台重新编译，但对此犹豫不决。我不明白为什么 veritysetup 不能接受字符设备？ Linux 似乎完全阻止对 mtdblock 设备的任何类型的写入，但允许对 mtd 设备进行写入。更让我困惑的是，我在网上发现了许多例子，人们在将 /dev/mtdblock 设备称为 data_devices 和 hash_devices 方面取得了明显的成功。我也发过帖这个问题在 cryptsetup gitlab issues 部分。