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

[Yeoreum Yun]

> 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().
> > 
> > > 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().
> 
> I don't remember when but I recall that this has been debated a few
> times and the idea of deferred TPM initialization has never been
> successful.

Yes. That's why handle the IMA at INIT_LATE_SYNC according to platform.
and when TPM RoTs is added, unless the the attestation module with is
initialised at late_initcall with IMA_INIT_LATE_SYNC option, platform
where TPM initailisation is deffered, this seems get failure to
recognise the TPM  RoT attestation according to current code example.

Might the TPM RoT attestation module would require some handling.
but I'm not sure with what fancy way.

-- 
Sincerely,
Yeoreum Yun