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

Daniel P. Berrangé posted 4 patches 3 weeks, 6 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20221107143910.972928-1-berrange@redhat.com
There is a newer version of this series
build-aux/syntax-check.mk                |   1 +
docs/manpages/meson.build                |   1 +
docs/manpages/virt-qemu-sev-validate.rst | 359 +++++++++++++++
libvirt.spec.in                          |   2 +
tools/meson.build                        |   5 +
tools/virt-qemu-sev-validate             | 555 +++++++++++++++++++++++
6 files changed, 923 insertions(+)
create mode 100644 docs/manpages/virt-qemu-sev-validate.rst
create mode 100755 tools/virt-qemu-sev-validate
[libvirt PATCH v4 0/4] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Daniel P. Berrangé 3 weeks, 6 days ago
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

Daniel P. Berrangé (4):
  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

 build-aux/syntax-check.mk                |   1 +
 docs/manpages/meson.build                |   1 +
 docs/manpages/virt-qemu-sev-validate.rst | 359 +++++++++++++++
 libvirt.spec.in                          |   2 +
 tools/meson.build                        |   5 +
 tools/virt-qemu-sev-validate             | 555 +++++++++++++++++++++++
 6 files changed, 923 insertions(+)
 create mode 100644 docs/manpages/virt-qemu-sev-validate.rst
 create mode 100755 tools/virt-qemu-sev-validate

-- 
2.37.3