On Mon, 2024-02-12 at 12:16 -0800, Dionna Amalie Glaze wrote: > 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.
I haven't seen that patch, but I presume it's not relevant? > 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 Are you referring to measured direct boot? In that case, there's no point having hashes in the fw_cfg, because OVMF in the guest needs to hash the kernel itself and then compare to a trusted source (which the fw_cfg file wouldn't be because it's under the control of the hypervisor). For SEV, the trusted source is a table in the launch measured ROM, but I'm sure TDX does something similar. > 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. Well, no, since firmware tends to update on a longer timeframe than the kernel and the cmdline and initrd tend to have quicker update cycles than the kernel. Thus there's no one golden reference. Instead you give a tool (say the virtee sev_snp_measure tool https://github.com/virtee/sev-snp-measure ) the hashes of the firmware, kernel, command line and initrd and it caclulates the expected launch measure > 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. That's because it's a pre-launch measure. The TCG log is only for post launch. The idea being those values are needed for you to approve something in pre-launch, like key release, before the TPM starts running. That's not to say we shouldn't have log entries for pre-launch, but that's a generic problem and not specific to measured direct boot. > 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. This sounds like a first measurement thing. In many ways, the pre- launch measurement is equivalent to the SRTM of a physical system which is collected in the EV_S_CRTM_* events. But for that to happen, I think the TCG would have to bless it in some form. James > 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)
