On Thu, Oct 20, 2022 at 08:18:20AM -0400, Cole Robinson wrote: > 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. I consider this similar to compiler warning files - we opt in to the biggest set of checks that we can cope with, and periodically consider if there any new ones we might like. Certainly don't want to just blindly enable all of them, nor have an exclusion list. 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 :|
