[RFC] Allowing SEV attestation

[Daniel P. Berrangé]

On Thu, May 06, 2021 at 12:22:26PM +0200, Michal Prívozník wrote:
> Dear list,
> 
> 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].

As mentioned in my reply to that thread, I believe we can already do
pretty much all of that via a combination of libvirt APIs & guest XML.

The query-sev / query-sev-capabilities info is exposed via the domain
capabilities API.

The initial startup of the attestation process is doable via the
QEMU CLI, and libvirt populates that from info in the domain XML
doc.

We have an API to query the measurement mapping to query-sev-launch-measure
and we hav the ability to start a guest in the paused state, so that it
doesn't immediately run guest CPUs.

The bit I don't see us implementing is the sev-inject-launch-secret
command. I guess we need a new API for that.

> 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?

Definitely not talk to QEMU directly. That has always been a bad idea
for anything, because QEMU is a constantly evolving app, and libvirt
needs to provide stability on that moving base.

> 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.

We made a half-hearted attempt at being generic in the current APIS and
XML we've done so far for SEV, but I'm not especially convinced it will
be good enough for TDX too.  Time will tell.

Given that we have most of the stuff for SEV already implemented, we've
already accepted that risk, so finishing the job for SEV isn't making
the situation significantly worse for us.


> 
> 
> 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
> 

Regards,
Daniel
-- 
|: 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 :|