Re: [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support

From: Jason Gunthorpe

Date: Thu Oct 22 2026 - 09:18:57 EST


On Thu, Oct 22, 2026 at 08:26:29AM -0400, James Bottomley wrote:
> On Wed, 2026-10-21 at 11:35 -0300, Jason Gunthorpe wrote:
> > Maybe we can build a multiplexed scheme on the spare? I don't know.
>
> Direct sharing of PCRs is certainly possible, but not in all
> circumstances. To share a log, each logging entity must record entries
> in such a way that the relying party can disentangle them with absolute
> certainty. The problem with the latter is that both the TCG and the
> IMA log format have unmeasured (or advisory) log entries. You can fool
> a relying party trying to disentangle a combined log simply by
> converting the advisory entry of one logging entity to being the
> advisory entry of another and bingo, it disappears from the other log.

My understanding was the unmeasured entries exist only to help the
verifier understand the log structure, and what data is in the
log. Like you might record a firmware version so that the verifier can
locate the reference measurement.

If they are corrupted somehow then the verifier should fail to
understand or reconstruct the log and fail the verification.

It seems to me if corrupting them in any way compromises the
verification then that's a pretty catastrophic bug in the verifier..

Though I fully agree with the sentiment, sharing a PCR requires a
robust scheme for the verifier to recover everything. If we ever build
sharing we may not end up using TCG log format.

> trust the entity provisioning and running the vTPM. The closest we
> come to having an autonomously attested vTPM is the SVSM-vTPM in SEV-
> SNP which can give an attestation of the ephemeral EK tied to the
> launch measurement of the enclave.

I understood the AMD approach a little differently.. The verifier gets
a signed token from the CVM's ROT (in ARM terms the realm token) which
has a hash that includes all the vTPM code (launch measurement), and
the token's report_data/challange/nonce is a hash of the random EK the
vTPM code built at boot.

So the verifier can construct a chain from ROT, to the VTPM code, to
the EK, to the quote from the vTPM, to the PCRs.

One of the things we need to check in this series is how well it
represents the AMD scheme where we have the ROT signing lots of
different things depending on the GUID..

Jason