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

[Jason Gunthorpe <jgg@nvidia.com>]

On Sat, Oct 17, 2026 at 11:16:07AM -0700, Dionna Glaze wrote:

> > About 3 months ago we started looking simultaneously how to support
> > roots of trust (ROT) HW in place of TPM and how to respond to the
> > feedback on the netlink proposal for the TSM SPDM.
> 
> Given that I was tagged on this thread and not that one, I'd
> appreciate a pointer to which you mean.

https://lore.kernel.org/all/20260705220819.2472765-2-djbw@kernel.org/

And then later this:

https://lore.kernel.org/all/20260921131911.532d81f4@kernel.org/

Basically: No netlink.

> > We began talking about generalizing tsm_mr to handle more than just
> > "tsm" into a broader set of roots of trust, including TPM. In this way
> > it could act as a multiplexor for any measurement user in the kernel,
> > like IMA for example. I see others have independently come to a
> > similar conclusion that IMA needs ROT agility, but I also know that
> > DRTM needs the same ROT agility too.
> 
> +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.

By "ROT agility" I mean if you want to do an extend operation you
should not have to know the details of the HW holding the "PCR".

One of the APIs offered here is a HW agnostic extend that can be used
to build ROT agility into user space programs that are doing
logging. That's systemd-pcr-extend for example.

The extent of the TPM support is to be able to issue a PCR extend
triggered with a TPM command by the agnostic API. Not ambitious at
all.

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

Just a multiplexor. We have at least IMA and DRTM in the kernel that
need to do "PCR extend", and if we have a world where the ROT isn't a
TPM that operation need to be multiplexed to the right driver to do
the extend.

There have now been two proposals to do this inside IMA between TPM
and tsm mr, the point here that multiplexer doesn't belong inside IMA.

> > Bringing in the SPDM side, the netlink TLV uAPI fits nicely and can
> > expose all the structured binary data it has. SPDM is also effectively
> > a ROT without any measurement registers.
> 
> I would push back on SPDM being a ROT because you're talking about
> different devices.

I guess there are different of terminology conventions.. When I say
ROT I mean the HW IP block that does at least a measurement extend and
signing report function. If you look at a schematic diagram of a
modern server there are a dozen of these blocks.

Yes, only one of these is the ROT used to measure the CPU's boot, and
only one of these is the lead ROT for attestation.

When I talk to people building the PCIe devices they absolutely talk
about an iROT on their chip that measures the PCIe device's boot. SPDM
is the protocol they are using to allow the OS to interact with that
ROT.

I guess "attestation subsystem" is a clearer name after all.

> Any other SPDM communication would be for composite attestation by a
> lead attester that all gets bound under the ROT that the lead attester
> uses (presumably TPM).

Right, userspace uses SPDM to connect to the ROTs in devices, get
their attestations, then bind those results to the CPU's ROT.

> > name for this expanded purpose so we start calling this attestation
> > subsystem. "root of trust" subsystem would be another way to look at
> > it.
> 
> I don't see how a trusted security module is a bad name for this.

At least half the stuff we call TSM in Linux is "TEE Security Manager"
and it is a PCIe spec term. So there is this naming conflict..

Secondly, we are imaging including things like Alistair & Lukas's
entirely software based Link IDE flow and I've had some security
people express a strong opinion that we must not call such an entirely
software model "trusted security module". In their mind TSM is
something outside the OS..

> > The general notion is any root of trust can come with a single driver
> > and expose a bunch of different uAPIs. The modern most capable one
> > would be the CTLV based ioctl interface through a char dev, but in
> > cases like TDX the legacy uAPIs will also remain supported.
> 
> What capabilities are you trying to enable, though? I'm not really
> getting the picture.

Three basic problem statements:

1) If I want to extend a measurement I need device specific flows
   for TPM, CCA, TDX, SEV - and they are not discoverable
2) If I want to request a signed quote I need a different set of device
   specific flows for TPM, CCA, TDX, SEV and SPDM
3) If I want to add a new ROT driver it doesn't have a logical home.
   You'd have to awkwardly squeeze it into tsm report and tsm mr.

> If I was right about you referencing Alistair's patch series, then
> perhaps this is a clue?

That series is about adding a software SPDM and Link IDE flow for
platforms that don't have a real firmware based TSM.

> if we're leaving the SPDM message construction and
> interpretation to user space.

All the firmware based flows for PCIe run the SPDM protocol inside
FW. The OS and userspace won't have access to the SPDM messages.

From an SPDM perspective a full system may have a mixture of FW doing
SPDM on PCIe and Software doing SPDM on somethign liek 

Userspace probably won't have access to SPDM messages. There are too
many FW managed flows for PCI TSM for this to work. The uAPI here for
SPDM will be some least common denominator. Drivers take that LCD and
map it to their specific FW calls. Alistair's series will be able to
implement that LCD entirely in software, but since most server systems
seem to lock the link IDE controls under FW a SW SPDM is not going to
be widely usable for PCIe.

> > For example the end goal is for systemd report to be able to
> > dynamically enumerate all the ROTs in the system, include them in the
> > report, and generate signatures. Without necessarily requiring ROT
> > specific code.
> 
> What other than TPM quotes and signed SPDM message transcripts are you
> trying to cover?

I also want all the stuff that tsm_mr and tsm_report currently covers,
and other ROT HW blocks like Caliptra that people are building.

> If there are NDA'd docs to get more info on these, I'd like to work on
> getting my eyes on them.
> Are there some doc numbers I can ask my hardware engineering rep to
> pull? They manage vendor engagement.

I don't know about docs, but if you have your people reach out to your
NVIDI reps and mention this conversation I'm sure we can arrange a
NDA'd briefing.

Thanks,
Jason