[chalabi2]

Why

Confidential Akash workloads need durable Block storage whose DEK is released only after attestation. CDH must initialize a new volume and reopen it after a guest restart without treating a transient mount failure as authority to format data.

What changed

• add an additive sourceType: persistent LUKS2 filesystem path
• require a stable measured volumeId and signature-verified sealed.* reference
• bind the fetched DEK to the digest carried in the signed payload
• initialize only a completely zero, non-LUKS backing device
• persist initializing and ready state in a volume-bound LUKS label
• probe mapped content with blkid before mount or format
• format only an initializing volume with no recognized filesystem
• fail closed for ready-but-unformatted, foreign, ambiguous, indeterminate, wrong-key, and mismatched-mapper states
• emit a stable non-secret mount result event for canary proof
• preserve existing empty and encrypted behavior

The state label supports crash recovery; it is not an anti-rollback mechanism.

Validation

• formatting and git diff --check pass
• pure probe and format-authorization cases are table tested
• an ignored privileged Linux test covers every initialization crash boundary and verifies existing filesystem data is not reformatted
• the existing persistent lifecycle, wrong-key, foreign-label, mapper, mount-path, and VaultSecret tests remain in place
• the exact commit is pinned by agent: fail closed and hand persistent volumes to CDH kata-containers#1, which also packages the new blkid runtime dependency

The local macOS host cannot compile the Linux-only loop-device dependency, and this Akash fork does not expose runnable Actions workflows. The privileged loopback test therefore remains a required Linux qualification step before merge.

Scope

This PR does not add anti-rollback, DEK rotation, RIM support, read-only persistent mounts, or a generic wipe fallback. Storage provisioners must still hand CDH a deterministically clean new Block volume.

[cloud-j-luna]

I did not find major correctness issues overall. Just want to raise 2 points. the first-init cost is relevant, given the 1MB ZERO_SCAN_BUFFER_SIZE it would not surprise me if on a 1TB deployment, in a 1 GB/s volume throughput it would take ~15min. That's still quite relevant and should be transparent to the user. Then there is the mutex which seems to block per device, this should be no issue for other tenants but will block on multiple blocks (might just be a performance compromise)