容器镜像不支持 dm-verity 原生挂载，因其是文件级产物而非扇区对齐的块设备；需先物化为原始块文件并预生成 hash 树，或改用 dm-crypt integrity 模式、oci 签名+内容寻址等更现实方案。
容器镜像不支持 dm-verity 原生挂载
Linux 的 dm-verity 是块设备层的只读完整性校验机制，它依赖内核在 block layer 加载哈希树并验证每个扇区——而容器镜像（如 OCI image）是分层 tar 或 blob 的文件级产物，不是可直接 losetup 的块设备。你无法把一个 tar.gz 或 layer.tar 直接传给 veritysetup 创建 verity 设备。
常见错误现象：veritysetup format 报错 Invalid argument 或 No such device or address，本质是因为输入不是块设备或未对齐的原始二进制镜像。
- 必须先将镜像层“物化”为固定大小、扇区对齐的原始块文件（例如用
dd创建 4K 对齐的空盘，再用tar --format=posix -xf解出内容） - verity 要求数据区与 hash 区严格分离，且 hash 树需预生成；OCI 镜像没有内置 hash 树结构，需额外构建
- 容器运行时（如 runc、crun）不解析或挂载 verity 设备，即使你手动
dmsetup create出来，overlayfs或chroot也不会自动绑定它
替代路径：用 dm-crypt + detached header 实现镜像解密+校验
真正能落地的方式，是绕过 verity 的块校验逻辑，改用 dm-crypt 的 integrity 模式（kernel ≥5.10），它在加密通道内嵌入 AEAD 认证（如 aes-gcm），同时提供机密性与完整性保护。关键在于：镜像层需以加密 blob 形式分发，运行时用 keyring 注入密钥后映射为可信块设备。
使用场景：私有 registry 分发敏感镜像，宿主机可信、但磁盘/网络不可信；要求启动时拒绝篡改过的 layer blob。
- 构建阶段用
cryptsetup luksFormat --type luks2 --sector-size 4096 --cipher aes-gcm-random --integrity hmac-sha256加密 layer 原始块文件 - 必须启用
--integrity且指定--sector-size 4096，否则校验粒度不匹配 overlayfs 的 page cache 行为 - 运行时通过
keyctl padd将密钥注入 session keyring，再用cryptsetup open --key-file /dev/stdin解锁（避免密钥落盘） - 注意：Docker 不支持自定义 crypt 设备挂载；需改用
podman system service+ 自定义oci-runtimehook 或直接调runc
verity 仅适用于只读 rootfs 的静态验证场景
如果你坚持用 dm-verity，唯一可行路径是：把整个容器 rootfs 打包成一个固定大小的 squashfs 或 ext4 镜像，生成 verity hash tree，再通过 initramfs 在 early boot 阶段挂载。这已脱离“容器镜像”的常规分发模型，更接近安全启动的 embedded Linux 流程。
性能影响明显：verity 的 hash 树查找会增加每次 read() 的延迟，尤其小文件随机读；hash 树本身占空间（约镜像大小的 0.1%～0.5%，取决于 block size）。
- 生成 verity 镜像必须用
veritysetup format --data-block-size 4096 --hash-block-size 4096，否则容器内stat()或 mmap 可能因 block 对齐失败而报Input/output error - hash 树需随镜像一起分发（通常作为 sidecar blob），运行时由 custom entrypoint 调用
dmsetup create并 bind-mount 到/var/lib/containers/...下某路径 - OCI spec 中无 verity 字段，Kubernetes CRI 也不识别，意味着你得自己 patch containerd shim 或写 runtime wrapper
最现实的完整性方案其实是镜像签名 + 内容寻址
别硬套 kernel block layer 机制。OCI 生态原生支持 cosign 签名和 digest（如 sha256:abc...），这是文件级、分布式的完整性保障，且被 Docker Hub、GitHub Container Registry、Notary v2 全面支持。
容易被忽略的点：签名验证发生在 pull 阶段，而非容器启动瞬间；若镜像层在本地被篡改（如 docker save | tar -xf 后修改再 load），digest 失效但不会自动 re-pull —— 这需要配合 containerd 的 image signature verification plugin 或自定义 snapshotter。
- 用
cosign sign --key cosign.key <registry>/<image>@<digest></digest></image></registry>对 digest 签名，比对 tag 更可靠 - 运行时设置
containerd的[plugins."io.containerd.grpc.v1.cri".image_decryption]和signature_verification插件启用强制校验 - 注意：digest 是压缩后 blob 的哈希，若你用
buildkit构建时启用了cache-to=type=registry，需确保 registry 支持 OCI Image Index 的subject引用，否则签名可能绑定到中间层而非最终镜像
