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