[PATCH v2 15/15] efi/arm64: Implement ARM64 DRTM in the stub

[Jason Gunthorpe]

On Wed, Oct 21, 2026 at 12:24:40AM +0100, Yeoreum Yun wrote:
> One small question...
> 
> [..snipped..]
> 
> > +void efi_drtm_launch(void)
> > +{
> > +	if (efi_drtm_policy == EFI_DRTM_OFF)
> > +		return;
> > +
> > +	/*
> > +	 * No cache maintenance is required before the launch. v1.4B R42130 in
> > +	 * Table 22 "DCE preamble requirements" requires the DRTM_PARAMETERS to
> > +	 * be accessible as Normal Write-Back Cacheable, Inner Shareable memory,
> > +	 * so the DCE reads them coherently with the writes made above.  R45220
> > +	 * in Table 30 "DCE requirements for the DLME" then has the DCE clean
> > +	 * and invalidate the whole DLME region to the Point of Coherency before
> > +	 * it measures the DLME image, which covers both the Image itself and
> > +	 * the handoff struct placed in the DLME region. Thus once we jump into
> > +	 * the kernel with MMU and caches off the CPU will see everything the
> > +	 * stub wrote.
> > +	 */
> > +	arm_drtm_dynamic_launch(drtm_cfg.params_addr);
> 
> After launching, How to get eventlogs for measurement of DLEM if
> tpm_read_log_efi() is used? Doesn't it need to concatenate those
> event logs from DRTM eventlog in returned DLEM data?

My plan is a future series will return them as a discrete log bundle
through attestation subsystem. All of the logs will be available
consistently that way, CCGL, the EFI and ACPI ones..

And it will be logically linked to the ROT the DRTM uses in some
future ROT agile DRTM flow. So we can tell the difference between a
TPM bare metal launch into PCRs and something like a realm launch into
REMs.

Thanks,
Jason