docs(cryptpilot-fde): explain dm-verity/dm-crypt layering order rationale

cryptpilot-fde/docs/boot.md

@@ -153,6 +153,12 @@ This service executes before `initrd-root-device.target` and is the key stage fo
 
 The construction of the rootfs device chain varies depending on encryption configuration. If rootfs encryption is configured, the service first obtains the passphrase through a key provider and opens the LUKS2 encrypted volume, then establishes dm-verity on the decrypted device. If encryption is not configured, dm-verity is established directly on the rootfs logical volume.
 
+**Layering Order of dm-verity and dm-crypt**
+
+- CryptPilot adopts a "decrypt-then-verify" order: dm-crypt sits on the lower layer (close to the disk, performing decryption) and dm-verity sits on the upper layer (close to the filesystem, verifying plaintext), with the hash tree built over plaintext. This choice is based on two considerations: first, the root_hash is independent of the encryption key, so rotating keys or re-encrypting does not require rebuilding the hash tree, which lowers operational cost; second, a single reference value can attest multiple instances that use different keys, simplifying reference-value management in multi-tenant remote attestation scenarios.
+
+- By comparison, an alternative order places dm-verity below dm-crypt and builds the hash tree over ciphertext. This order follows the Encrypt-then-MAC cryptographic principle: it can verify disk integrity without unlocking the volume and avoids decrypting potentially tampered ciphertext, yielding a more rigorous security composition. The trade-off is that key rotation changes the entire on-disk ciphertext and forces a full rebuild of the hash tree, and the root_hash depends on the encryption key, requiring a separate reference value for each instance that uses an independent key, which is inconvenient for unified multi-tenant attestation. Weighing the practical requirements of the confidential computing scenario, CryptPilot chose the former.
+
 #### 4.1.1 Delta Volume Initialization and Expansion
 
 The service first checks whether the disk where the LVM physical volume resides has unallocated space, and if so, extends the partition table and expands the LVM physical volume. This mechanism enables the system to automatically adapt to disk expansion scenarios in cloud environments.

cryptpilot-fde/docs/boot_zh.md

@@ -153,6 +153,12 @@ Initrd阶段是系统盘加密方案的核心执行阶段，由systemd服务编
 
 rootfs设备链的构建根据加密配置有所不同。若配置了rootfs加密，服务首先通过密钥提供者获取passphrase并打开LUKS2加密卷，再在该解密设备上建立dm-verity。若未配置加密，则直接在rootfs逻辑卷上建立dm-verity。
 
+**dm-verity与dm-crypt的分层顺序**
+
+- CryptPilot采用"先解密、后校验"的顺序：dm-crypt位于下层（紧贴磁盘，负责解密），dm-verity位于上层（靠近文件系统，对明文校验），哈希树针对明文构建。该选择主要基于两点考量：其一，root_hash与加密密钥无关，轮换密钥或重新加密时无需重建哈希树，运维成本更低；其二，同一份参考值可度量使用不同密钥的多个实例，便于在多租户远程证明场景下统一管理参考值。
+
+- 作为对比，另一种顺序是将dm-verity置于dm-crypt之下，哈希树针对密文构建。该顺序符合"先认证后解密"（Encrypt-then-MAC）的密码学原则，可在不解锁的情况下校验磁盘完整性，避免对可能被篡改的密文执行解密，安全性组合更严谨；但其代价是密钥轮换会导致全盘密文变化而必须重建整棵哈希树，且root_hash依赖加密密钥，每个使用独立密钥的实例都需要独立的参考值，不利于多租户统一度量。综合机密计算场景的实际需求，CryptPilot选择了前者。
+
 
 #### 3.1.1 delta卷的初始化和扩容