On 10/18/22 5:22 AM, Daniel P. Berrangé wrote: > 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.
Pylint needs a lot of hand holding. Every distro upgrade you'll hit new issues, want to exclude more checks etc. I never looked into how projects use it for CI gating, seems kinda exhausting unless you only enable specific checks. - Cole
