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

[Jason Gunthorpe <jgg@nvidia.com>]

On Sun, Mar 22, 2026 at 09:43:49AM +0800, Pingfan Liu wrote:
> *** The history ***
> 
> Nowadays, UEFI PE bootable images are becoming increasingly popular
> among distributions. Currently, we have several kinds of image format
> parsers in user space (kexec-tools). However, this approach breaks the
> integrity protection of the images. To address this integrity protection
> concern, several approaches have been proposed to resolve this issue,
> but none of them have been accepted upstream yet.
> 
> The summary of those approaches:
>   -1. UEFI service emulator for UEFI stub
>   -2. PE format parser in kernel
>   -3. Signing the arm64/boot/Image

I recently had an interesting discussion with Ard around DRTM for
kexec and we sort of independently concluded that #1 would be the best
(only?) option there.

All the implementations of DRTM today live in the EFI stub and
intercept the boot process as it goes along. After ExitBootServices
the DRTM implementation will launch the kernel in a different way.
Even worse today's x86 version strongly requires EFI boot services to
connect the Linux stub with a trampoline helper provided earlier in
the boot chain.

A kexec flow that only works on decompressed vmlinux, with no option
to run any EFI code, is going to be difficult to support. There is
enough information and choices involved in DRTM that it is undesirable
for the predecessor kernel to try and DRTM launch it on behalf of the
successor, let alone trying to get the insane x86 trampolines into a
kexec successor kernel.

Given those constraints entering the successor kernel through the
normal EFI entry point is highly desirable. This would allow x86 to
continue to provide the DRTM trampolines through an EFI mechanism and
means the Linux EFI stub always handles the launch with identical code
in all scenarios.

I reviewed the earlier threads and it wasn't clear why this was
abandoned? The points Ard raised are legitimate, but I would respond
to them:

https://lore.kernel.org/lkml/20240819145417.23367-1-piliu@redhat.com/T/#m8519beebccb252861b257db390a1686686b27aeb

> 1)  Implementing UEFI entirely is intractable, and unnecessary.

Yes, I think that is the entire point of the general idea, that we
should strive to have some limited EFI that is just useful enough to
boot a UKI through to the kernel EFI entry point.

> 2)  Running the UEFI emulator on bare metal is not going to scale.

Well, I don't think everyone will have that choice. At least DRTM
requires things like ARM SMCs, and x86 requires ACPI parsing, it would
be really tricky to get those things into a userspace context.

I would recast this idea as "having the kernel community own a UEFI
emulator for every kind of bare metal is not scalable"

> 3. We need to figure out how to support TPM and PCRs in the context
> of kexec.

AFAIK it doesn't really work today. DRTM significantly fixes it, and
passing more PCR logs fixes it even more. Though I don't see that it
has much to do with using the EFI entry point.. It is a good question
what should systemd-shim do in a kexec case, or more generally when
DRTM is being used. (for drtm it should probably not do anything with
PCRs)


IMHO, the kernel shouldn't get involved. It shouldn't try to integrate
an EFI emulator. The kexec path in the kernel should allow userspace
to provide a signed executable which is the emulator it wants to use
and let other people sort it out in their own projects. Distros can
sign the emulators they like.

There are already two examples of emulators that can EFI Boot the
kernel so there is definitely something achievable that many people
can use. If someone wants to go crazy and support Grub, console,
userspace EFI, etc, they can do that on their own git :)

Down this path the kernel work should simply be supporting a signed
executable (not vmlinux), and a robust way to pass more information
through a FDT to that executable. Such that userspace can get the EFI
emulator, the UKI, side cars and anything else nicely organized and
labeled in a FDT so the EFI emulator has an easy job.

In the current AI fueled world this looks much more tractable than it
did in 2024 when this was last brought up.

Regards,
Jason