On 5/6/21 8:32 AM, Daniel P. Berrangé wrote: > On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote: >> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote: >>>> 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. >> >> This is not a good user experience. The entire attestation process >> should be made ephemeral, taking place 100% over a socket. Enabling a >> fully socket-based attestation workflow will decouple it from the domain >> XML and the host file system and make it easier for guest-owner tooling >> to facilitate attestation. > > The libvirt library is also just a client talking to a socket, so > concept that's no different, just using a protocol libvirt has defined > at a higher level instead of a low level hypervisor specific protocol. > > The tools that are managing the VM lifecycle are already using libvirt > as their API, and already doing several of the steps described wrt to > SEV. It is not realistic to expect them to take a completely different > approach to managing the startup of VMs that have SEV enabled, they > need to have a way to integrate with their existing approach to mgmt. > > The guest owner has to in turn talk to some mechanism that the > management app exposes to them. These management apps are pretty > unlikely to wish to directly expose a low level impl detail of QEMU. > They won't even expose the fact that they're using libvirt in fact, > instead presenting some higher level API again, as they rarely wish > to leak low level hypervisor details outside as that locks them into > supporting specific low level details long term. I see. So it sounds like the way forward for libvirt is that it will need to essentially duplicate the SEV-related QMP message types into its own protocol since expecting the client to understand QMP discloses the fact that the underlying hypervisor is QEMU. Connor
