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

[Jarkko Sakkinen]

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.

One key atom is prepared to be robust in early environments i.e.,
struct tpm_buf. I rewrote it as it is the atom here albeit not very
visible change as itself.

I think rest is to define how to cut and decouple the current code,
and how it is split to source modules so that the right stuff gets 
linked to the target binaries.

I think with enough trouble tpm_tis for instance could have a flagged
early boot version. I would actually do a tpm_tis_early.c source module
for this, which would never be linked to kernel but would wire like
the rest of the driver to the framework.

The actual hard part is to re-engineer tpm_chip, tpm_chip_ops and
transmit flow perhaps so that the framework is easy to decouple,
structs are not pain to manage in early boot code, and that
type off stuff, which you really need to just fight through.

Overall, there's work but not really "unknown unknowns". I'm happy
to review this but have limited capacity to push through the bushes
as I have my hands full of keyrings right now.


> Consider that you have to do a lot of command interpretation to know
> whether a user is getting or extending a PCR value, or whether it's
> systemd doing an NVPCR thingamajig.
> I don't think you can intercept commands and translate to intent for
> any kind of extension to be correctly tracked by your MR journalling
> addition here.
> Can you explain a little more what your intent is?

I'm a bit lost of the context here but I have a tool, which I think is
the most accurate TPM2 protocol presentation there really is but it is in
Rust:

https://crates.io/crates/tpm2-protocol

It has zero-copy data types for TPM2, it can interpret and present
both commands and response at the scale of the whole TCG spec, has
zero dependencies, does not allocate memory i.e. can point directly
into wire and is from the get go to be importable to an enclave
entry point, OS kernels and pre-boot firmware.

It is designed to be importable and test harness compiles only with
rustc to demonstrate this.

I don't know how much it is used but at least Valve is doing
something with it.

Br, Jarkko