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(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.
Ok sounds good, I'll leave it as is
Thanks,
Cole