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

Cole Robinson crobinso at redhat.com
Wed Nov 9 15:33:29 UTC 2022


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 at redhat.com>

- Cole


More information about the libvir-list mailing list