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(a)redhat.com>
>> ---
>> include/libvirt/libvirt-domain.h | 22 ++++++++++++++++++++++
>> src/qemu/qemu_driver.c | 23 +++++++++++++++++++++++
>> 2 files changed, 45 insertions(+)
>>
>
> Reviewed-by: Michal Privoznik <mprivozn(a)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.
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 :|