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