[RFC] Allowing SEV attestation

Jim Fehlig jfehlig at suse.com
Tue Oct 26 23:29:00 UTC 2021

On 5/6/21 04:22, Michal Prívozník wrote:
> Dear list,

Hi Michal,

This thread has been quiet for a long time, but I wanted to check if any work 
has been done to provide an sev-inject-launch-secret equivalent for libvirt. 
AFAICT, there was agreement this missing piece is needed to solve the 
attestation puzzle. Did you make any progress? If so, I can help with testing 
and review. If not, I can take a stab at it.


> in the light of recent development of secure virtualization (for instance AMD
> SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new
> technologies and thus would like to discuss our options. So far, I've came
> across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to
> adopt its newer version too.
> Consider the following example: you loan a VM on a public cloud and you want
> to process some private data there. Of course, the data has to be stored on an
> encrypted disk/partition. But encrypting guest memory (confidentiality)
> prevents you only from finding the key in a memory dump. It doesn't help if
> the guest image, initial guest memory, hypervisor or firmware were tampered with.
> This is where attestation comes to help - it enables the guest owner (which in
> this example is different to the one running it) verify - with cryptographic
> level of confidence - that data confidentiality and integrity can be ensured.
> Depending on the technology, attestation will be done at different times in
> the VM lifecycle. When it's done before starting guest vCPUs, it's called
> pre-attestation and when it's done after the guest has launched, it's called
> post-attestation. For example, AMD SEV and SEV-ES require pre-attestation.
> SEV-SNP allows for post attestation. The crux of the issue here is that *when*
> and *how* the guest owner will interact with the VM for attestation will be
> different depending on which technology is being used.
> It looks like QEMU will expose commands needed for attestation via QMP [3].
> But question then is, how to expose those at Libvirt level? Should we allow
> users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in
> public APIs, or something completely different?
> Will those APIs be generic enough to serve other technologies too? For
> instance, given set of APIs in given order works for SEV but might not work
> for Intel's TDX.
> 1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-support-thomas-lendacky-amd
> 2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
> 3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html
> Michal

More information about the libvir-list mailing list