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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Oct 21, 2026 at 09:08:36AM +0100, Yeoreum Yun wrote:
> > +	image_size = le64_to_cpu(header->image_size);
> > +	measured_offset = info->drtm_measured_start;
> > +	measured_size = info->dlme_measured_size;
> > +	entry = info->drtm_entry;
> > +	dlme_start = image_base + image_size;
> > +	dlme_end = dlme_start + drtm_cfg.dlme_data_size;
> > +	dce_end = dlme_end + drtm_cfg.nw_dce_size;
> 
> Suppose user boot the kernel via decompressed Image which is the
> part of artifact of compressed image and use the drtm option (e.g.
> booting via UEFI shell with decompressed Image).

Yep, it works fine:

EFI stub: DRTM: interface version 1.4
EFI stub: DEBUG: DRTM: TPM algorithm 0xc, TPM hashing unavailable, PCR schemas 0x1
EFI stub: DEBUG: DRTM: minimum DLME data 73728 bytes, Normal-world DCE 0 bytes
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Exiting boot services...
EFI stub: DEBUG: DRTM: will launch, selected launch features 0x0

Notice there is no "Decompressing Linux Kernel"

> Since the drtm extra memory is allocated only in efi_zboot_entry(),
> I think the drtm extra memory wouldn't be allocated so it would corrupt
> memory while setting the laucn parameter or by DRTM...

Patch "efi/libstub: Have efi_kaslr_relocate_kernel() handle
extra_size" handles the Image case.

Thanks,
Jason