Re: [libvirt PATCH 02/12] tools: support validating SEV firmware boot measurements
On 10/20/22 8:11 AM, Cole Robinson wrote:
> On 10/18/22 5:15 AM, Daniel P. Berrangé wrote:
>> On Sun, Oct 16, 2022 at 02:54:47PM -0400, Cole Robinson wrote:
>>> On 10/7/22 7:42 AM, Daniel P. Berrangé wrote:
The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
domain launch measurement, to a computed launch measurement. This
determines whether the domain has been tampered with during launch.
This initial implementation requires all inputs to be provided
explicitly, and as such can run completely offline, without any
connection to libvirt.
The tool is placed in the libvirt-client-qemu sub-RPM since it is
specific to the QEMU driver.
Signed-off-by: Daniel P. Berrangé
>>>
+try:
+check_usage(args)
+
+attest(args)
+
+sys.exit(0)
+except AttestationFailedException as e:
+if not args.quiet:
+print("ERROR: %s" % e, file=sys.stderr)
+sys.exit(1)
+except UnsupportedUsageException as e:
+if not args.quiet:
+print("ERROR: %s" % e, file=sys.stderr)
+sys.exit(2)
+except Exception as e:
+if args.debug:
+traceback.print_tb(e.__traceback__)
+if not args.quiet:
+print("ERROR: %s" % e, file=sys.stderr)
+sys.exit(3)
>>>
>>> This only tracebacks on --debug for an unexpected error. I think it's
>>> more useful to have --debug always print backtrace. It helped me
>>> debugging usage of the script
>>
>> Ok, I can do that.
>>
>> Do you recall what sort of problems required you to be looking at
>> the debug output ? Wondering if there's anything we can do to make
>> it more foolproof for less knowledgable users ?
>>
>
> I was running the script from git, but against an older running libvirtd
> which did not support the cpu XML, and the error didn't call
> that out specifically. I thought about suggesting an explicit error for
> that case but I think it's unlikely to happen in the real world.
>
Hmm I see now that I did actually suggest this elsewhere :P
- Cole
Re: [libvirt PATCH 02/12] tools: support validating SEV firmware boot measurements
On 10/18/22 5:15 AM, Daniel P. Berrangé wrote:
> On Sun, Oct 16, 2022 at 02:54:47PM -0400, Cole Robinson wrote:
>> On 10/7/22 7:42 AM, Daniel P. Berrangé wrote:
>>> The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
>>> domain launch measurement, to a computed launch measurement. This
>>> determines whether the domain has been tampered with during launch.
>>>
>>> This initial implementation requires all inputs to be provided
>>> explicitly, and as such can run completely offline, without any
>>> connection to libvirt.
>>>
>>> The tool is placed in the libvirt-client-qemu sub-RPM since it is
>>> specific to the QEMU driver.
>>>
>>> Signed-off-by: Daniel P. Berrangé
>>
>>> +try:
>>> +check_usage(args)
>>> +
>>> +attest(args)
>>> +
>>> +sys.exit(0)
>>> +except AttestationFailedException as e:
>>> +if not args.quiet:
>>> +print("ERROR: %s" % e, file=sys.stderr)
>>> +sys.exit(1)
>>> +except UnsupportedUsageException as e:
>>> +if not args.quiet:
>>> +print("ERROR: %s" % e, file=sys.stderr)
>>> +sys.exit(2)
>>> +except Exception as e:
>>> +if args.debug:
>>> +traceback.print_tb(e.__traceback__)
>>> +if not args.quiet:
>>> +print("ERROR: %s" % e, file=sys.stderr)
>>> +sys.exit(3)
>>
>> This only tracebacks on --debug for an unexpected error. I think it's
>> more useful to have --debug always print backtrace. It helped me
>> debugging usage of the script
>
> Ok, I can do that.
>
> Do you recall what sort of problems required you to be looking at
> the debug output ? Wondering if there's anything we can do to make
> it more foolproof for less knowledgable users ?
>
I was running the script from git, but against an older running libvirtd
which did not support the cpu XML, and the error didn't call
that out specifically. I thought about suggesting an explicit error for
that case but I think it's unlikely to happen in the real world.
- Cole
Re: [libvirt PATCH 02/12] tools: support validating SEV firmware boot measurements
On Sun, Oct 16, 2022 at 02:54:47PM -0400, Cole Robinson wrote:
> On 10/7/22 7:42 AM, Daniel P. Berrangé wrote:
> > The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
> > domain launch measurement, to a computed launch measurement. This
> > determines whether the domain has been tampered with during launch.
> >
> > This initial implementation requires all inputs to be provided
> > explicitly, and as such can run completely offline, without any
> > connection to libvirt.
> >
> > The tool is placed in the libvirt-client-qemu sub-RPM since it is
> > specific to the QEMU driver.
> >
> > Signed-off-by: Daniel P. Berrangé
>
> > +try:
> > +check_usage(args)
> > +
> > +attest(args)
> > +
> > +sys.exit(0)
> > +except AttestationFailedException as e:
> > +if not args.quiet:
> > +print("ERROR: %s" % e, file=sys.stderr)
> > +sys.exit(1)
> > +except UnsupportedUsageException as e:
> > +if not args.quiet:
> > +print("ERROR: %s" % e, file=sys.stderr)
> > +sys.exit(2)
> > +except Exception as e:
> > +if args.debug:
> > +traceback.print_tb(e.__traceback__)
> > +if not args.quiet:
> > +print("ERROR: %s" % e, file=sys.stderr)
> > +sys.exit(3)
>
> This only tracebacks on --debug for an unexpected error. I think it's
> more useful to have --debug always print backtrace. It helped me
> debugging usage of the script
Ok, I can do that.
Do you recall what sort of problems required you to be looking at
the debug output ? Wondering if there's anything we can do to make
it more foolproof for less knowledgable users ?
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 02/12] tools: support validating SEV firmware boot measurements
On 10/7/22 7:42 AM, Daniel P. Berrangé wrote:
> The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
> domain launch measurement, to a computed launch measurement. This
> determines whether the domain has been tampered with during launch.
>
> This initial implementation requires all inputs to be provided
> explicitly, and as such can run completely offline, without any
> connection to libvirt.
>
> The tool is placed in the libvirt-client-qemu sub-RPM since it is
> specific to the QEMU driver.
>
> Signed-off-by: Daniel P. Berrangé
> +try:
> +check_usage(args)
> +
> +attest(args)
> +
> +sys.exit(0)
> +except AttestationFailedException as e:
> +if not args.quiet:
> +print("ERROR: %s" % e, file=sys.stderr)
> +sys.exit(1)
> +except UnsupportedUsageException as e:
> +if not args.quiet:
> +print("ERROR: %s" % e, file=sys.stderr)
> +sys.exit(2)
> +except Exception as e:
> +if args.debug:
> +traceback.print_tb(e.__traceback__)
> +if not args.quiet:
> +print("ERROR: %s" % e, file=sys.stderr)
> +sys.exit(3)
This only tracebacks on --debug for an unexpected error. I think it's
more useful to have --debug always print backtrace. It helped me
debugging usage of the script
Thanks,
Cole
[libvirt PATCH 02/12] tools: support validating SEV firmware boot measurements
The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
domain launch measurement, to a computed launch measurement. This
determines whether the domain has been tampered with during launch.
This initial implementation requires all inputs to be provided
explicitly, and as such can run completely offline, without any
connection to libvirt.
The tool is placed in the libvirt-client-qemu sub-RPM since it is
specific to the QEMU driver.
Signed-off-by: Daniel P. Berrangé
---
docs/manpages/meson.build| 1 +
docs/manpages/virt-qemu-sev-validate.rst | 207 ++
libvirt.spec.in | 15 ++
tools/meson.build| 9 +
tools/virt-qemu-sev-validate.py | 257 +++
5 files changed, 489 insertions(+)
create mode 100644 docs/manpages/virt-qemu-sev-validate.rst
create mode 100755 tools/virt-qemu-sev-validate.py
diff --git a/docs/manpages/meson.build b/docs/manpages/meson.build
index ba673cf472..f14028659a 100644
--- a/docs/manpages/meson.build
+++ b/docs/manpages/meson.build
@@ -19,6 +19,7 @@ docs_man_files = [
{ 'name': 'virt-pki-validate', 'section': '1', 'install': true },
{ 'name': 'virt-qemu-run', 'section': '1', 'install': conf.has('WITH_QEMU')
},
{ 'name': 'virt-xml-validate', 'section': '1', 'install': true },
+ { 'name': 'virt-qemu-sev-validate', 'section': '1', 'install':
conf.has('WITH_QEMU') },
{ 'name': 'libvirt-guests', 'section': '8', 'install':
conf.has('WITH_LIBVIRTD') },
{ 'name': 'libvirtd', 'section': '8', 'install': conf.has('WITH_LIBVIRTD') },
diff --git a/docs/manpages/virt-qemu-sev-validate.rst
b/docs/manpages/virt-qemu-sev-validate.rst
new file mode 100644
index 00..36de9becfd
--- /dev/null
+++ b/docs/manpages/virt-qemu-sev-validate.rst
@@ -0,0 +1,207 @@
+==
+virt-qemu-sev-validate
+==
+
+
+validate a domain AMD SEV launch measurement
+
+
+:Manual section: 1
+:Manual group: Virtualization Support
+
+.. contents::
+
+SYNOPSIS
+
+
+
+``virt-qemu-sev-validate`` [*OPTIONS*]
+
+
+DESCRIPTION
+===
+
+This program validates the reported measurement for a domain launched with AMD
+SEV. If the program exits with a status of zero, the guest owner can be
+confident that their guest OS is running under the protection offered by the
+SEV / SEV-ES platform.
+
+Note that the level of protection varies depending on the AMD SEV platform
+generation and describing the differences is outside the scope of this
+document.
+
+For the results of this program to be considered trustworthy, it is required to
+be run on a machine that is already trusted by the guest owner. This could be a
+machine that the guest owner has direct physical control over, or it could be
+another virtual machine protected by AMD SEV that has already had its launch
+measurement validated. Running this program on the virtualization host will not
+produce an answer that can be trusted.
+
+OPTIONS
+===
+
+Common options
+--
+
+``-h``, ``--help``
+
+Display command line help usage then exit.
+
+``-d``, ``--debug``
+
+Show debug information while running
+
+``-q``, ``--quiet``
+
+Don't print information about the attestation result.
+
+Guest state options
+---
+
+These options provide information about the state of the guest that needs its
+boot attested.
+
+``--measurement BASE64-STRING``
+
+The launch measurement reported by the hypervisor of the domain to be
validated.
+The measurement must be 48 bytes of binary data encoded as a base64 string.
+
+``--api-major VERSION``
+
+The SEV API major version of the hypervisor the domain is running on.
+
+``--api-minor VERSION``
+
+The SEV API major version of the hypervisor the domain is running on.
+
+``--build-id ID``
+
+The SEV build ID of the hypervisor the domain is running on.
+
+``--policy POLiCY``
+
+The policy bitmask associated with the session launch data of the domain to be
+validated.
+
+Guest config options
+
+
+These options provide items needed to calculate the expected domain launch
+measurement. This will then be compared to the reported launch measurement.
+
+``-f PATH``, ``--firmware=PATH``
+
+Path to the firmware loader binary. This is the EDK2 build that knows how to
+initialize AMD SEV. For the validation to be trustworthy it important that the
+firmware build used has no support for loading non-volatile variables from
+NVRAM, even if NVRAM is expose to the guest.
+
+``--tik PATH``
+
+TIK file for domain. This file must be exactly 16 bytes in size and contains
the
+unique transport integrity key associated with the domain session launch data.
+This is mutually exclusive with the ``--tk`` argument.
+
+``--tek PATH``
+
+TEK file for domain. This file must be exactly 16 bytes in size and contains
the
+unique transport encryption key
