[libvirt PATCH 02/12] tools: support validating SEV firmware boot measurements

[Cole Robinson]

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é <berrange at redhat.com>
>>>
>>>> +    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 <signature> 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