Re: AMD SEV-SNP encryption at rest
On Fri, Oct 11, 2024 at 01:11:43PM -0000, me+libvirt(a)gsora.xyz wrote:
Hello folks,
I’m exploring the capabilities of the AMD SEV-SNP platform for a TEE implementation that
will handle and store secret data.
This data should be tied to a single guest, that is no other guest that boots with the
same kernel/initrd/cmdline - in the form of a UKI - should be able to decrypt it.
I have a prototype that encrypts the boot disk with a key derived from the VCEK, but a
different guest is able to derive the same key provided it boots either the same UKI.
The key has been derived with the snpguest tool developed by the virtee project.
Does anybody have experience with encryption at rest with the AMD SEV SNP platform?
I understand that it’s possible to inject secrets into a SEV VM at creation time, but
documentation is scarce on that front.
The secret injection support in libvirt is exclusively for SEV + SEV-ES,
there's nothing for SNP.
SEV-SNP is a quite different architecture, moving attestation report
creation from the host, into the guest, which requires a different
way of working with the guest.
Development in the context of SNP is still very active and most attention
is around the Coconut SVSM project. Amongst other things, this is intended
to provide a vTPM to the SNP guest, at which point it is expected that
users will use the standard mechanisms for sealing LUKS keyslots against
the TPM. This is something systemd already supports for example.
If you look at Microsoft Azure, this is the approach that the provided
RHEL and Ubuntu images are already taking for disk encryption with both
SNP and Intel TDX.
As such, personally, I would not recommend investing time developing a
disk encryption scheme that is directly tied to SNP specific concepts.
Relying on the TPM is a better bet, as it means the encryption solution
is able to work in the same way across bare metal, traditional VMs and
confidential VMs[1]
With regards,
Daniel
[1] NB, I generally exclude SEV/SEV-ES when talking about 'confidential'
VMs since they have a number of unfixable flaws, which require SEV-SNP
to address
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|