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
