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

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 16 Oct 2026, at 16:41, Jason Gunthorpe wrote:
> 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!
>

Excellent news!

> 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
>

Interesting. I'm not sure this is a reliable workaround, though, given
that the return from ExitBootServices() occurs as a result of another
syscall(), and the kthread is long gone by then.

I think the reliable approach here is taking down all the other cores
before doing the kexec.

> 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
>

I've dropped that requirement already - the TTBR0 side can just switch
to 4k pages.

> 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'?
>

That is only #define'd when CONFIG_ARM64_PA_BITS_52 is set. I don't think
we should be using that directly, though - I'll investigate.

>    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.
>

Same problem, I suppose?

>    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.
>

I think this is related to the use of the 'alloc' API, which my efiloader
crate uses but does not exist in the same way in the kernel. I'll look into
this as well.

In other news, I've added some other features to the prototype: x86_64
support, support for UKIs including sidecars etc (the kexec image loader
now accepts a cpio archive which can be presented as the ESP) and some
other improvements. This is highly in flux so let's compare notes often
so things do not diverge unnecessarily.