RFC i386/sev: kernel-hashes, reference measurements and event logs

[Dionna Amalie Glaze]

This is not a patch but it felt inappropriate to derail a recent patch
that's just refactoring the kernel-hashes object_class_property
definition. Apologies if this has been discussed before, as I'm not
particularly active here.

Regarding kernel-hashes, how is that load-time information passed
along to the guest beyond, say, OVMF? Can we require that these hashes
are also present in fw_cfg so they can be read from the kernel? In
Linux it'd be nice to have /sys/firmware/qemu_fw_cfg/sev_kernel_hash,
/sys/firmware/qemu_fw_cfg/sev_cmdline_hash,
/sys/firmware/qemu_fw_cfg/sev_initrd_hash

I'm working on how to use standard document formats for providing
reference measurements of the Google Compute Engine virtual firmware
for remote attestation, and these hashes have an impact not just on
the measurement but on the entire model that the IETF RATS working
group is considering for authorizing attestation measurements.

If you're assembling a VM launch configuration with firmware provided
by a trusted vendor (say Google), and your hashes are passed in from
an API, there's no easy rendezvous to state that the combination
produces the expected hardware measurement. This makes adding
kernel-hashes support unappetizing, since it makes the hardware
attestation report's measurement have no meaning, or at least, it
makes life difficult for people trying to assign it meaning.

The measurement is the product of two different entities as assembled
by the VMM given a trusted firmware and the kernel hashes. It's a bit
of a sandwich of (GCE) core firmware, (User) SEV hashes, (GCE) BSP
VMSA, AP VMSA*.

When you collect "evidence" to verify locally or pass along to a
verification service, you need more than just the hardware attestation
report to make sense of the combined bits. You have a PCR situation
like with TPM, so you need an event log for these different aspects of
the ultimate measurement. There is no event log for this
-kernel-hashes construction.

We can use the TCG TPM event log to post EV_NO_ACTION events about the
PlatformRIM, specifically, to point at a UEFI variable that we
populate to store our signed document about the expected measurements
with the Qemu-SEV-SNP-boot-protocol, but I don't see how we might
collect the kernel-hashes values as extra evidence to combine and
derive the attestation report's MEASUREMENT field to accept "evidence"
objects for the core firmware component and the kernel hashes
component.

So my question is if this feature is to be a long term feature, how do
you expect to collect the SEV hashes as a separate evidence object to
play nicely with IETF RATS?

Is this a long term feature, or are we expecting it to be deprecated by SVSM?

I've tagged in people in CC that I could imagine would have something
to say about this.

Thanks y'all

--
-Dionna Glaze, PhD (she/her)