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

[James Bottomley]

On Thu, 2026-10-22 at 10:11 -0300, Jason Gunthorpe wrote:
> 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. 

That's true, but only if you know the entire log consists of your
measurements.  Because you know, ipso facto, that you should be able to
understand them all.

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

Not if you corrupt them to make them look like an entry belonging to
another log.  If you're the exclusive owner of the PCR you know you
have to be able to understand every entry, but if you're entangled with
another log, you can't process its entries, so with exclusive ownership
you can't discard an entry but with shared ownership, you can because
you make the discarded entry look like it belongs to the other log.

> 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.

That is more or less what I said.  For actual details, they're in the
SVSM spec:

https://lore.kernel.org/linux-coco/39cc8435-5643-4a16-8eb5-5e12f15566a1@xxxxxxx/

So it's actually the hash of the nonce supplied plus the vTPM
attestation report that's put into the nonce field of the PSP
attestation report.  The proof that it came from the SVSM is the fact
that it's recorded as being requested at VMPL0.

> 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..

Well, I like the ephemeral scheme because I helped invent it.  However,
we are under pressure to provide a persistent vTPM as well

https://github.com/coconut-svsm/svsm/pull/1195

so attestation of that becomes a bit more problematic because you need
a chain of custody to prove the seeds didn't leak.

Regards,

James