Expected PCRs are troublesome

[deeglaze]

As a first attempt to get a good sense of a boot environment, signed PCRs for reference measurements may work okay, but they are often the result of "boot, snapshot, ship it" and not the result of individually vetted events that are the result of measuring a diaspora of build artifacts.

On TDX we don't have a vTPM natively. Instead we have 4 runtime measurement registers and a Confidential Compute Event Log (CCEL). Since these registers are not used for sealing secrets like PCRs are, we are freer to disrupt their stability. We treat them purely as integrity protection for the event log, which an attestation verifier has policy to evaluate and accept or reject. See github.com/google/go-tpm-tools or Keylime for example policies.

In large computing ecosystems, we have components like ACPI tables, NUMA node configuration, secure boot variables, and GRUB2 commands that all get measured and accounted for in the event log. Different teams are responsible for vetting these configurations, and they should produce their own signed reference values for the events they give rise to. It's not particularly helpful to understand the software supply chain when the integrator needs to trust at first touch all their combinations, and even throw away some measurements as "don't care" because they're too noisy.

If at all possible, it'd be great for anyone interested in this space to come collaborate with me and Keylime developers on a reference value profile for PC Client event logs, upon which we can extend to TDVF CCEL https://github.com/deeglaze/draft-pfp-corim-spec/

Given the synthesis of supply chain information, I think it's important to focus on integrating with standards that OEMs are advised to follow.