On 11/7/22 9:41 AM, Daniel P. Berrangé wrote: > The libvirt QEMU driver provides all the functionality required for > launching a guest on AMD SEV(-ES) platforms, with a configuration > that enables attestation of the launch measurement. The documentation > for how to actually perform an attestation is severely lacking and > not suitable for mere mortals to understand. IOW, someone trying to > implement attestation is in for a world of pain and suffering. > > This series doesn't fix the documentation problem, but it does > provide a reference implementation of a tool for performing > attestation of SEV(-ES) guests in the context of libvirt / KVM. > > There will be other tools and libraries that implement attestation > logic too, but this tool is likely somewhat unique in its usage of > libvirt. Now for a attestation to be trustworthy you don't want to > perform it on the hypervisor host, since the goal is to prove that > the hypervisor has not acted maliciously. None the less it is still > beneficial to have libvirt integration to some extent. > > When running this tool on a remote (trusted) host, it can connect > to the libvirt hypervisor and fetch the data provided by the > virDomainLaunchSecurityInfo API, which is safe to trust as the > key pieces are cryptographically measured. > > Attestation is a complex problem though and it is very easy to > screw up and feed the wrong information and then waste hours trying > to figure out what piece was wrong, to cause the hash digest to > change. For debugging such problems, you can thus tell the tool > to operate insecurely, by querying libvirt for almost all of the > configuration information required to determine the expected > measurement. By comparing these results,to the results obtained > in offline mode it helps narrow down where the mistake lies. > > So I view this tool as being useful in a number of ways: > > * Quality assurance engineers needing to test libvirt/QEMU/KVM > get a simple and reliable tool for automating tests with. > > * Users running simple libvirt deployments without any large > management stack, get a standalone tool for attestation > they can rely on. > > * Developers writing/integrating attestation support into > management stacks above libvirt, get a reference against > which they can debug their own tools. > > * Users wanting to demonstrate the core SEV/SEV-ES functionality > get a simple and reliable tool to illustrate the core concepts > involved. > > Since I didn't fancy writing such complex logic in C, this tool is > a python3 program. As such, we don't want to include it in the > main libvirt-client RPM, nor any other existing RPM. THus, this > series puts it in a new libvirt-client-qemu RPM which, through no > co-inicidence at all, is the same RPM I invented a few days ago to > hold the virt-qemu-qmp-proxy command. > > Note, people will have already seen an earlier version of this > tool I hacked up some months ago. This code is very significantly > changed since that earlier version, to make it more maintainable, > and simpler to use (especially for SEV-ES) but the general theme > is still the same. > > Changed in v4: > > - Fixed loading of initrd/cmdline from XML > - s/loader/firmware/ in some error messages > > Changed in v3: > > - Remove LUKS specific --disk-password and have generic > --inject-secret > - Fix handling of optional initrd/cmdline > - Require --kernel if --initrd or --cmdline are present > - Ensure VM is in paused state > > Changed in v2: > > - All the suggestions from Cole and Kashyap > Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> - Cole
