[libvirt PATCH 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation

Daniel P. Berrangé berrange at redhat.com
Tue Oct 18 09:22:13 UTC 2022


On Sun, Oct 16, 2022 at 03:06:17PM -0400, Cole Robinson wrote:
> On 10/7/22 7:42 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.
> > 
> > Daniel P. Berrangé (12):
> >   build-aux: only forbid gethostname in C files
> >   tools: support validating SEV firmware boot measurements
> >   tools: load guest config from libvirt
> >   tools: support validating SEV direct kernel boot measurements
> >   tools: load direct kernel config from libvirt
> >   tools: support validating SEV-ES initial vCPU state measurements
> >   tools: support automatically constructing SEV-ES vCPU state
> >   tools: load CPU count and CPU SKU from libvirt
> >   tools: support generating SEV secret injection tables
> >   docs/kbase: describe attestation for SEV guests
> >   scripts: add systemtap script for capturing SEV-ES VMSA
> >   docs/manpages: add checklist of problems for SEV attestation
> 
> 
> After the fix I mentioned on patch 7, the script worked for my sev,
> sev-es, sev-es + kernel setup, with vmsa passed in and vmsa generated.
> 
> Attached is some pylint output, nothing really serious:

We've not run pylint on libvirt tree historically, but I wonder
if we should introduce it to check all our build scripts too.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list