[背景]
我正在开发一个嵌入式 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 部分。