Re: [RFC] Allowing SEV attestation
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.
--
/kashyap