[PATCHv7 00/13] kexec: Use BPF lskel to enable kexec to load PE format boot image

[Jason Gunthorpe]

On Wed, Oct 14, 2026 at 06:39:14AM +0200, Ard Biesheuvel wrote:

> > I've asked some folks here to take a look and try to test this with
> > real DRTM capable HW. It seems very promising that it will work to me,
> > and I surmize this is also close to boot a UKI?
> 
> It already works for UKIs as well.
> 
> The next step is to run it deprivileged - I think the arm64 stub code
> is already very close to being runnable in that manner.

Abhishek was able to test it on some Grace hardware, and investigate
the DRTM. He was able to show it works, using some FW debugging to the
serial port and the post-kexec dmesg:

 <kexec>
   INFO:    DRTM service handler: version
   INFO:    DRTM service handler: get error
   INFO:    ++ DRTM service handler: TPM features
   INFO:    ++ DRTM service handler: Min. mem. requirement features
   INFO:    ++ DRTM service handler: DMA protection features
   INFO:    ++ DRTM service handler: Boot PE ID features
   INFO:    DRTM service handler: dynamic launch

   [..]

   [  10.655030] DRTM: launch completed

So this solution is absolutely viable for DRTM kexec. Great!

He had a couple of issues, I will try to summarize them as I
understood them.

1) ARM DRTM requires that the executing CPU be the boot CPU when
   launching the kernel. My patches enforced this in the EFI stub
   assuming that the EFI stub will be the same CPU as after exit boot
   services. Since the kthread has no CPU assignment it picks
   something random and fails these checks:

   [ 3219.695710] kexec_efi: EFI stub: ERROR: DRTM: boot PE 0x20000 does not match current PE 0x430000
   [ 3219.695726] kexec_efi: EFI stub: WARNING: DRTM: preparation failed, continuing without DRTM
   [ 3219.732742] kexec_efi: EFI image suspended at ExitBootServices(), system table @ 0x1001bff00090

   The kthread this runs in picks a random CPU so it doesn't
   work. Abhishek was able to put a kthread_bind() in to always use
   the boot CPU

2) Most of our systems use 64K page size, so the restriction in the
   series is not great. Abhishek used a 4k predecessor kernel and
   confirmed he could boot a 64k successor

3) Some compile glitches:

   1. arch/arm64/kernel/kexec_efi.c:175:35: error: 'PTE_ADDR_HIGH'
   undeclared (first use in this function); did you mean 'PTE_ADDR_LOW'?

   2. KEXEC_EFI_STUB declares depends on ARM64_4K_PAGES but nothing about
   PA_BITS, so a 4K + 48-bit-PA config does not compile.

   3. With rustc 1.85.0, which is what scripts/min-tool-version.sh asks
   for on arm64, the link fails:

     ld: arch/arm64/kernel/kexec_efi_glue.o: undefined reference to
     `__rust_no_alloc_shim_is_unstable'

     ld: rust/alloc.o: undefined reference to `__rust_alloc_error_handler_should_panic'

   He used rustc 1.96.0 instead and it builds fine.

Thanks,
Jason