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

[Daniel P. Berrangé]

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.

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 :|