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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2026-10-20 at 17:11 +0100, Yeoreum Yun wrote:
> > On Tue, 2026-10-20 at 11:06 -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2026 at 09:45:13AM -0400, Mimi Zohar wrote:
[...]
> > > > To support this framework, IMA requires a strict, atomic
> > > > execution sequence to maintain the Measure → Extend → Execute
> > > > (Measure Before Use) guarantee. This initializes early during
> > > > the late_initcall phase within the initramfs (via dracut).
> > > > 
> > > > If the new subsystem introduces a direct kernel-to-kernel
> > > > multiplexing call path, how will it ensure the mandatory
> > > > synchronous wait behavior when extending multiple hardware
> > > > backends?
> > > 
> > > Everything has this 'measure before use' requirement. Why would
> > > this be hard? Just loop over all the configured measurement
> > > targets if thats the plan? Maybe I'm missing something?
> > 
> > As long as the measurements aren't queued, but actually wait for
> > the multiple ROTs to complete, it isn't a problem.

Just to be super precise about this, it's the extension of the
measurement to the TPM that must be contemporaneous.  We have a few
examples in UEFI where the TPM gets extended and then a bit later (when
more stuff is ready) the log entry gets added.

Just on the waiting for ROTs to complete ... that's not accurate for a
TPM: the ROT, which is effectively the initial measurement, completed
long ago (in TPM terms this is the RTM - Root of Trust for
Measurement).  The problem is actually a communication problem not a
readiness one, see below.

> 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).
> 
> In particular, when I see breifly proviers/tdx.c and imange for TPM,
> once if it's failed to get tpm_default_chip() in module_init(),
> There is no way to retry and TPM seems not to be exported as RoT
> device.
> 
> Am I missing something?

Mimi already answered the main thrust of this, but there's a corollary:
because of the early init requirements, the TPM driver must be
available before the first non-EFI kernel measurement is made, which
means TPM drivers can't be modules.

The reason for the above in a UEFI system is because the
ExitBootServices() call in the EFI stub kills the UEFI TPM driver, so
there's no way of using the TPM between that call and the kernel
initializing its own TPM driver.  I've often thought that if we could
prevent that and have a separate callback to kill the UEFI TPM driver
(or probably one before ExitBootServices to say please keep this driver
and then another to say I'm done), we could effectively use that for
early kernel measurements and then engineer a handover to the in-kernel
driver and then not be too worried about when the in-kernel driver
attaches.  Of course, doing all this would require a UEFI spec update,
which means it's not a quick or easy thing.

Regards,

James