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

[Philipp Rudo <prudo@redhat.com>]

Hi Jason,
Hi Ard,

let me add my 2 ct as well.

On Tue, 13 Oct 2026 21:19:28 +0200
"Ard Biesheuvel" <ardb@kernel.org> wrote:

> Hi Jason,
> 
> Thanks for chiming in.
> 
> On Sun, 11 Oct 2026, at 22:13, Jason Gunthorpe wrote:
> > 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.
> >  
> 
> With some help from my friend Claude, I've prepared a prototype that
> reuses my efiloader Rust crate to boot EFI stub images (bare Image,
> zboot, UKI) in the kernel: the EFI boot phase is invoked at kexec
> load time, and runs under the preceding kernel up until the point
> where ExitBootServices() is called. Then, the actual kexec call
> will return from ExitBootServices() after shutting down the first
> kernel.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efiloader-kexec

I only took a brief look and cannot claim to fully understand your
solution, yet. Nevertheless I'm pretty impressed. I also agree that
this approach is by far the best, if we can get it to work.

The reason why I and Pingfan abandoned this approach and went for eBPF
instead was due to security concerns. Our premise is/was that the EFI
stub must not be able to harm the running kernel. Be it intentional or
not. That's a guarantee eBPF with its verifier can give but a simple
file signature can't.

I believe the way Ard ties execution of the EFI stub to module
signature verification solves the "intentionally malicious" case. In
the end it doesn't make sense to try to prevent a malicious EFI stub to
be executed when an attacker could also load a malicious kernel module.

But that still leaves the "unintentional malicious" case. Meaning,
that someone tries to be "smart" and does weird stuff in the EFI stub
he knows it won't do any harm during cold boot, but that will cause
problems to the kernel running the efiloader. IIUC Ard's implementation
cannot catch such problems. But I expect it will be a total pain to
debug them. Especially when it is caused by some out-of-tree stub.

To be honest, I'm not sure how this could be solved. I'm not even sure
if it's worth trying. Nevertheless I believe it's worth having some sort
of tainted flag. At least that would give developers a hint that some
untrusted code was run without them spending ours of debugging.

Two more comments with my distro head on.

First, kdump is extremely important to us. So the final solution needs
to be able to load a crash kernel as well.

Second, implementing the efiloader in Rust is not ideal. This prevents
us to support the feature in older streams that don't support
Rust4Linux.

Anyway, thanks for bringing up the topic again. I'm looking forward to
see the next version.

Thanks
Philipp

> 
> There are some limitations (4k pages only, CONTIG_ALLOC support
> required) but it seems to work as expected.
> 
> I haven't looked at measured boot or DRTM specifics.
> 
>