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

Daniel P. Berrangé posted 12 patches 1 year, 5 months ago
Failed in applying to current master (apply log)
There is a newer version of this series
build-aux/syntax-check.mk                |    1 +
docs/kbase/launch_security_sev.rst       |  102 ++
docs/manpages/meson.build                |    1 +
docs/manpages/virt-qemu-sev-validate.rst |  643 +++++++++++
examples/systemtap/amd-sev-es-vmsa.stp   |   48 +
libvirt.spec.in                          |   15 +
tools/meson.build                        |    9 +
tools/virt-qemu-sev-validate.py          | 1289 ++++++++++++++++++++++
8 files changed, 2108 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.py
[libvirt PATCH 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Daniel P. Berrangé 1 year, 5 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.

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       |  102 ++
 docs/manpages/meson.build                |    1 +
 docs/manpages/virt-qemu-sev-validate.rst |  643 +++++++++++
 examples/systemtap/amd-sev-es-vmsa.stp   |   48 +
 libvirt.spec.in                          |   15 +
 tools/meson.build                        |    9 +
 tools/virt-qemu-sev-validate.py          | 1289 ++++++++++++++++++++++
 8 files changed, 2108 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.py

-- 
2.37.3

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

- Cole
************* Module virt-qemu-sev-validate
tools/virt-qemu-sev-validate.py:88:35: W0622: Redefining built-in 'format' (redefined-builtin)
tools/virt-qemu-sev-validate.py:101:41: W0622: Redefining built-in 'format' (redefined-builtin)
tools/virt-qemu-sev-validate.py:151:16: C0200: Consider using enumerate instead of iterating with range and len (consider-using-enumerate)
tools/virt-qemu-sev-validate.py:351:8: W0201: Attribute 'cr0' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:352:8: W0201: Attribute 'rip' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:354:8: W0201: Attribute 'cs_selector' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:355:8: W0201: Attribute 'cs_base' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:356:8: W0201: Attribute 'cs_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:358:8: W0201: Attribute 'ds_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:360:8: W0201: Attribute 'es_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:361:8: W0201: Attribute 'fs_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:362:8: W0201: Attribute 'gs_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:363:8: W0201: Attribute 'ss_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:365:8: W0201: Attribute 'gdtr_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:366:8: W0201: Attribute 'idtr_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:368:8: W0201: Attribute 'ldtr_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:369:8: W0201: Attribute 'tr_limit' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:371:8: W0201: Attribute 'dr6' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:372:8: W0201: Attribute 'dr7' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:373:8: W0201: Attribute 'rflags' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:374:8: W0201: Attribute 'xcr0' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:379:8: W0201: Attribute 'cr4' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:382:8: W0201: Attribute 'efer' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:386:8: W0201: Attribute 'ldtr_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:403:8: W0201: Attribute 'ldtr_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:390:8: W0201: Attribute 'tr_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:405:8: W0201: Attribute 'tr_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:393:8: W0201: Attribute 'g_pat' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:433:8: W0201: Attribute 'g_pat' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:407:8: W0201: Attribute 'cs_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:412:8: W0201: Attribute 'ds_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:416:8: W0201: Attribute 'es_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:420:8: W0201: Attribute 'ss_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:424:8: W0201: Attribute 'fs_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:428:8: W0201: Attribute 'gs_attrib' defined outside __init__ (attribute-defined-outside-init)
tools/virt-qemu-sev-validate.py:542:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:564:12: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:569:12: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:571:27: W0622: Redefining built-in 'str' (redefined-builtin)
tools/virt-qemu-sev-validate.py:573:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:639:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:642:12: W0715: Exception arguments suggest string formatting might be intended (raising-format-tuple)
tools/virt-qemu-sev-validate.py:647:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:650:12: W0715: Exception arguments suggest string formatting might be intended (raising-format-tuple)
tools/virt-qemu-sev-validate.py:658:12: W0715: Exception arguments suggest string formatting might be intended (raising-format-tuple)
tools/virt-qemu-sev-validate.py:663:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:664:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:669:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:683:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:688:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:703:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:708:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:725:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:740:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:768:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:772:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:773:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:831:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:832:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:938:8: W1201: Use lazy % formatting in logging functions (logging-not-lazy)
tools/virt-qemu-sev-validate.py:947:14: I1101: Module 'lxml.etree' has no 'fromstring' member, but source is unavailable. Consider adding this module to extension-pkg-allow-list if you want to perform analysis based on run-time introspection of living objects. (c-extension-no-member)
tools/virt-qemu-sev-validate.py:1025:18: I1101: Module 'lxml.etree' has no 'fromstring' member, but source is unavailable. Consider adding this module to extension-pkg-allow-list if you want to perform analysis based on run-time introspection of living objects. (c-extension-no-member)
tools/virt-qemu-sev-validate.py:1122:16: W0621: Redefining name 'args' from outer scope (line 1251) (redefined-outer-name)
tools/virt-qemu-sev-validate.py:1186:11: W0621: Redefining name 'args' from outer scope (line 1251) (redefined-outer-name)
tools/virt-qemu-sev-validate.py:43:0: C0411: standard import "import logging" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:45:0: C0411: standard import "import os" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:46:0: C0411: standard import "import re" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:47:0: C0411: standard import "import socket" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:48:0: C0411: standard import "from struct import pack" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:49:0: C0411: standard import "import sys" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:50:0: C0411: standard import "import traceback" should be placed before "import libvirt" (wrong-import-order)
tools/virt-qemu-sev-validate.py:51:0: C0411: standard import "from uuid import UUID" should be placed before "import libvirt" (wrong-import-order)
Re: [libvirt PATCH 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Daniel P. Berrangé 1 year, 5 months ago
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.


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 :|

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

Re: [libvirt PATCH 00/12] tools: provide virt-qemu-sev-validate for SEV(-ES) launch attestation
Posted by Daniel P. Berrangé 1 year, 5 months ago
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 :|