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

[Mimi Zohar]

On Wed, 2026-10-21 at 10:51 -0300, Jason Gunthorpe wrote:
> On Wed, Oct 21, 2026 at 08:23:05AM -0400, Mimi Zohar wrote:
> > On Tue, 2026-10-20 at 13:52 -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2026 at 05:11:03PM +0100, Yeoreum Yun wrote:
> > > > But, I have a related concern about deferred probing of RoT devices.
> > > > 
> > > > For example, if TPM probing is deferred until after the attestation
> > > > subsystem has been initialized, how would the subsystem handle the
> > > > TPM becoming available later (This is reason for
> > > > IMA_INIT_LATE_SYNC).
> > 
> > FYI, this patch set initializes at module_initcall(), not even late_initcall().
> 
> Yeah, it's fine for where this patch series is.
> 
> > > I don't think it would be any different, the mechanism for TPM would
> > > become generalized and apply to any attestation driver.
> > > 
> > > This series doesn't attempt to do that flow yet, moving ima over and
> > > dealing with this is another series :)
> > 
> > When TPM device initialization is deferred, it is retried during
> > late_initcall().
> > 
> > As there is no way of ordering within an initcall level, there is a race between
> > the device driver probing and the call to late_initcall(). The solution was to
> > allow IMA to register at late_initcall_sync() based on a Kconfig.
> > 
> > Both device_initcall() and module_initcall() are at level 6. Are you sure:
> > • the PCIe SPDM Devices will be ready at module_initcall()?
> > • the PCIe SPDM Devices are not deferred to late_initcall()?
> 
> Why does SPDM need to get involved here? The device acceptance flow
> and SPDM stuff will be managed in the initrd. The subsystem can accept
> drivers and load a TPM/etc earlier while doing SPDM later. That's fine.

If there are no PCIe SPDM ROTs, then it is irrelevant.  Otherwise, the question
is whether the PCIe SPDM device will be ready at module_initcall().

> 
> AFAICT IMA needs its ROT to be loaded before we reach the initrd.

Being able to measure the early initrd measurements would be nice.

Mimi

> 
> DRTM also needs a ROT loaded much earlier as we need to measure ACPI
> (and the initrd?).
> 
> I imagine attestation subsystem will eventually have to be ready to
> accept drivers prior to ACPI.
> 
> ARM's DRTM architecture splits the ACPI into parts that are already
> secured/measured somehow, and then other parts that the OS is
> responsible to measure itself. This split is arranged so the OS can
> discover the TPM through ACPI using only secured ACPI tables.
> 
> Thus we need to parse enough of the ACPI to get the TPM driver loaded,
> an attestation driver for it, and then continue to parse the rest of
> the ACPI that wasn't already secured.
> 
> Yikes! I dread making all of those things.. But that's an option for
> the required shape of things.
> 
> Jason