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

Daniel P. Berrangé posted 12 patches 1 year, 4 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20221107144127.973324-1-berrange@redhat.com
build-aux/syntax-check.mk                |    1 +
docs/kbase/launch_security_sev.rst       |  105 ++
docs/manpages/meson.build                |    1 +
docs/manpages/virt-qemu-sev-validate.rst |  666 +++++++++++
examples/systemtap/amd-sev-es-vmsa.stp   |   48 +
libvirt.spec.in                          |    2 +
tools/meson.build                        |    5 +
tools/virt-qemu-sev-validate             | 1335 ++++++++++++++++++++++
8 files changed, 2163 insertions(+)
create mode 100644 docs/manpages/virt-qemu-sev-validate.rst
create mode 100644 examples/systemtap/amd-sev-es-vmsa.stp
create mode 100755 tools/virt-qemu-sev-validate
[libvirt PATCH v4 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Daniel P. Berrangé 1 year, 4 months 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é (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

 build-aux/syntax-check.mk                |    1 +
 docs/kbase/launch_security_sev.rst       |  105 ++
 docs/manpages/meson.build                |    1 +
 docs/manpages/virt-qemu-sev-validate.rst |  666 +++++++++++
 examples/systemtap/amd-sev-es-vmsa.stp   |   48 +
 libvirt.spec.in                          |    2 +
 tools/meson.build                        |    5 +
 tools/virt-qemu-sev-validate             | 1335 ++++++++++++++++++++++
 8 files changed, 2163 insertions(+)
 create mode 100644 docs/manpages/virt-qemu-sev-validate.rst
 create mode 100644 examples/systemtap/amd-sev-es-vmsa.stp
 create mode 100755 tools/virt-qemu-sev-validate

-- 
2.37.3

Re: [libvirt PATCH v4 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Cole Robinson 1 year, 4 months ago
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@redhat.com>

- Cole