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

[Jason Gunthorpe]

On Thu, Oct 15, 2026 at 04:50:33PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@xxxxxxxxxx>
> 
> Linux has several attestation interfaces tied to individual technologies.
> That makes evidence retrieval, measurement registers, device state and
> kernel consumers provider-specific.
> 
> This series introduces a common attestation subsystem. Its goal is to
> support platform, TEE and device providers through one model, including
> TPM2, TDX, SEV-SNP, Arm CCA, FIRME, Caliptra and PCI/TSM-backed devices.
> This first series implements the common subsystem and a TDX provider.
> Existing native TDX tsm_mr and tsm_report interfaces remain independent.

To add some more colour on where this came from for others..

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.

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.

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.

Combining the two needs together it seemed apparent that TSM is a bad
name for this expanded purpose so we start calling this attestation
subsystem. "root of trust" subsystem would be another way to look at
it.

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.

In this way I view it as a further evolution of the tsm report and tsm
mr components in a way that lets us harmonize the uAPI and avoid
hardcoding things in userspace. Though the name has changed so this
linage is not quite as apparent.

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.

This applies to SPDM as well, ultimately every SPDM user in the kernel
should be able to get an attestation subystem cdev and flow through
the same uAPI channels that PCIe TSM uses, also into systemd for
measuring and logging.

I'm looking at something like 7-10 ROT drivers just for the current
set of NVIDIA ARM servers. Probably another ~5 for NVDIA non-ARM
servers. Then a couple more down the road. It is alot of variety and
today all this HW is largely unavailable through Linux.

Jason