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)
