On Wed, Oct 21, 2026 at 11:06:49AM -0300, Jason Gunthorpe wrote: > 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. I think i misread that patch. :) -- Sincerely, Yeoreum Yun
