Skip to content

Conversation

@kvinwang
Copy link
Collaborator

Summary

  • Fix encrypted ZFS persistence issue: VMs with encrypted ZFS storage were reformatting the disk on every reboot. The is_disk_initialized() check required both LUKS header AND zpool detection for encrypted ZFS, but zpool import is attempted before LUKS is opened, which always fails. Now for encrypted filesystems, we only check LUKS header presence.

  • Fix dcap-qvl security vulnerability: Update dcap-qvl from 0.2.0 to 0.3.10 in key-provider-build/Cargo.lock to fix "Missing Verification for QE Identity" (dependabot alert Implement tdxctl remove-orphans #95).

Test plan

  • Verified ext4 encrypted storage persists across VM reboots with KMS key provider
  • Verified ZFS encrypted storage persists across VM reboots with KMS key provider (after fix)
  • Confirmed no "Creating ZFS filesystem" on reboot, only "LUKS header detected" and successful pool import

The functions were not specific to ECDSA:
- derive_ecdsa_key was a generic HKDF key derivation, now renamed to derive_key
- derive_ecdsa_key_pair was specifically for P-256, now renamed to derive_p256_key_pair
- derive_ecdsa_key_pair_from_bytes similarly renamed to derive_p256_key_pair_from_bytes

This makes the API clearer about what each function actually does.
Problem: VMs with encrypted ZFS storage were reformatting the disk on
every reboot, even with KMS or local key provider enabled.

Root cause: The is_disk_initialized() check required both LUKS header
AND zpool detection for encrypted ZFS (line 1057-1058). However, zpool
import is attempted on the raw encrypted device (/dev/vdb1) before LUKS
is opened, which always fails since the ZFS pool is inside the LUKS
container.

Solution: For any encrypted filesystem (ext4 or ZFS), only check for
LUKS header presence, since the actual filesystem can only be detected
after opening LUKS. This aligns encrypted ZFS handling with encrypted
ext4, which was already using this approach.

Testing: Verified with both ext4 and ZFS encrypted storage that disk
now persists across VM reboots when key provider is enabled.
Update dcap-qvl from 0.2.0 to 0.3.10 to fix:
- Missing Verification for QE Identity (GHSA-xxx)

This fixes dependabot alert #95.
@kvinwang kvinwang closed this Jan 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants