[PATCH] qemu: Report sev measurement value and nonce explicitly

[Cole Robinson]

On 10/26/22 7:24 AM, Daniel P. Berrangé wrote:
> On Tue, Oct 25, 2022 at 03:03:46PM -0400, Cole Robinson wrote:
>> On 10/17/22 3:42 AM, Michal Prívozník wrote:
>>> On 10/16/22 22:06, Cole Robinson wrote:
>>>> The value returned by qemu's query-sev-launch-measure comes
>>>> straight from the LAUNCH_MEASURE SEV firmware command. It's two
>>>> values packed together: first 32 bytes is the launch measurement,
>>>> last 16 bytes is the nonce.
>>>>
>>>> This combined value is really just an artifact of the return value
>>>> of the firmware command, it has no direct usage. Users want the two
>>>> individual values. But because qemu and libvirt do not separate them
>>>> apart, every app that wants to process this value will have to do
>>>> it manually.
>>>>
>>>> This performs the split for the user, and delivers the values in two
>>>> new TYPED_PARAM fields: sev-measurement-value, sev-measurement-nonce
>>>>
>>>> Signed-off-by: Cole Robinson <crobinso at redhat.com>
>>>> ---
>>>>  include/libvirt/libvirt-domain.h | 22 ++++++++++++++++++++++
>>>>  src/qemu/qemu_driver.c           | 23 +++++++++++++++++++++++
>>>>  2 files changed, 45 insertions(+)
>>>>
>>>
>>> Reviewed-by: Michal Privoznik <mprivozn at redhat.com>
>>>
>>
>> Thanks, but thinking more, I'll propose this at the qemu layer and make
>> sure it's acceptable there first. Otherwise long term tools will may
>> still need to handle the sev-measurement format to cover both qemu and
>> libvirt cases.
> 
> I'm not entirely convinced we should split them apart at either
> libvirt or QEMU level.
> 
> I think I would tend to view CVM launch measurement data as being
> an opaque blob from the POV of libvirt/QEMU. In the case of SEV/SEV-ES
> it does represent a tuple of nonce+hash, but that encoding is an
> artifact of the current firmware implementation. The firmware <->
> userspace API for SEV treats it as opaque, which means the firmware
> has the freedom to change its contents at will. I expect this is
> unlikely to happen in practice, but it is allowed for by the current
> design, as we transmit the firmware major/minor version, alongside
> the measurement.  If we split them apart then it makes QMEU and
> libvirt aware of the specific firmware implementation which is
> undesirable.
> 
> Overall I'd say the only 2 parties who should try to interpret the
> measurement are the firmware and the attestation software client,
> all the pieces inbetween should remain dumb transports.

Ok sounds good, I'll leave it as is

Thanks,
Cole