On 5/6/21 6:35 AM, Kashyap Chamarthy wrote:
> 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?"
Would this be acceptable if libvirt could apply a policy to the QMP
socket which only allowed SEV messages through and dropped all others
(just for an example)? If it's possible to leverage the existing QMP API
for the attestation messages, then libvirt won't have to duplicate a
lower-level attestation protocol.
This would allow libvirt to essentially proxy relevant messages and this
moves all the attestation complexity to the "edges" (i.e., the
client/relying party and the VMM).
Connor