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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Sat, Oct 17, 2026 at 05:55:57PM -0300, Jason Gunthorpe wrote:
> On Sat, Oct 17, 2026 at 10:06:04PM +0300, Jarkko Sakkinen wrote:
> > On Sat, Oct 17, 2026 at 11:16:07AM -0700, Dionna Glaze wrote:
> > > +Jarkko
> > > The TPM driver is pretty entrenched and heavily used by different user
> > > space applications, so it seems really ambitious to bundle in TPM
> > > here.
> > 
> > This is something on the table thanks to Trenchboot and its early boot
> > code.
> 
> I've proposed that there be no early TPM in the Linux DRTM
> implementation. The trampoline would just do a bit of additional work
> with its existing TPM code before it reaches Linux.
> 
> https://lore.kernel.org/all/20261016165135.GA494690@nvidia.com/

Maybe really would want to see a PoC of this.

> 
> My intention with attestation subsystem: tpm and DRTM is to follow the
> ARM design and get ACPI up enough to reach a HW driver. Attestation
> subsystem will multiplex the DRTM "PCR" logging to which ever ROT that
> DRTM launch selected. This is another reason why I dont like early TPM
> because it turns from just early TPM, already hard, into
> early-every-ROT which is much worse.

Earlyboot code could be done with just C by having TCG compatible
device parts in a "TIS lib" and "CRB lib" but yeah, this will
inevitably hit into having to upscale hardware over TCG MMIO.

So yeah, I think I get the negatives. This is what bothers me
a bit also in Trenchboot patch set. Arbitrary context dependent
hardware support for TPM does sound a bit risky...

> 
> I view all the stuff you are listing to make tpm early work as too
> difficult compared to just having the trampoline do it since it
> already must have a TPM extend operation inside it.

OK, thanks for sharing this, and I'm not arguing against this.

> 
> Jason

Br, Jarkko