Loading post…
Red HatVitaly KuznetsovTutorial
Self-encrypting VM images for confidential environments hands on
Summary
Confidential VM technologies such as AMD SEV-SNP and Intel TDX protect runtime data but leave persistent storage protection to the guest OS. This article demonstrates a method using Fedora Rawhide that combines dm-verity integrity for the immutable base image with a dm-crypt encrypted overlay for mutable parts. The base /usr partition remains verity-protected, while on first boot systemd-repart creates an encrypted root partition with a key sealed to the virtual TPM, ensuring each VM gets a unique key. An overlay filesystem mounts the immutable base under the writable overlay, avoiding a full copy of the base image and reducing boot time significantly in cloud environments. The article also outlines current limitations, including the lack of proof of origin for the overlay partition and the absence of integrity or replay attack protection.
Context
Confidential VM technologies like AMD SEV-SNP and Intel TDX protect runtime data but leave persistent storage protection to the guest OS. The challenge is to create a VM image where the base image is verifiable and mutable parts are encrypted with unique keys per instance, without compromising boot time.
Approach / What changed
Create a VM image with a dm-verity-protected /usr partition and empty space. On first boot, systemd-repart creates a dm-crypt encrypted root partition using TPM sealing. An overlay filesystem combines the immutable base with the encrypted writable overlay.
Takeaways
The base image uses dm-verity for integrity, making the genuine image verifiable via a Merkle tree and roothash passed to the kernel.
On first boot, an encrypted overlay is created using systemd-repart with TPM sealing, ensuring each VM gets a unique encryption key.
The overlay approach avoids a full copy of the base image, reducing boot time compared to copying the verity content to a new partition.
FAQ
How does the VM verify the base image integrity?
The base image uses dm-verity, which provides runtime integrity via a Merkle tree. The roothash is passed to the kernel, and the kernel verifies data blocks against this hash to detect tampering.
How is the encryption key unique per VM?
The encrypted partition is created on first boot using systemd-repart with TPM sealing. The key is sealed to the VM's virtual TPM, so each VM gets a unique key that cannot be used by another instance.
What are the limitations of this approach?
The approach only supports trivial storage configurations, lacks proof of origin for the overlay partition, and does not offer integrity or replay attack protection. A malicious host could pre-create an overlay and seal it to the vTPM.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.