[RFC] Allowing SEV attestation

[Kashyap Chamarthy]

On Thu, May 06, 2021 at 12:22:26PM +0200, Michal Prívozník wrote:

Hi,

(Just chiming in as a curious libvirt API user :-))

[...]

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

I know you're just thinking out loud here, but IIUC, isn't allowing
libvirt API users to communicate directly with QEMU in this case
departing from the libvirt norm?  (Perhaps there's scope of sensible
exceptions ... as the devil is in the specs.)

Allowing a way to do it is one thing — which is nice for testing and
development — but saying "just directly communicate via QMP passthrough"
makes the libvirt API user wonder "why is it okay to passthrough QMP
commands in this case, but generally such an action is marked as
'tainted' by libvirt?"

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

That's a tough question, I guess, on the "API genericness".  I have not
read the specifictations of AMD and Intel in full; only read them in
parts ... but "ideally" (I know), a single set of libvirt APIs would
abstract AMD's and Intel's implementation details.
 
> 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
> 

-- 
/kashyap