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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Oct 20, 2026 at 07:47:19PM +0200, Philipp Rudo wrote:

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

This seems too much to me, I think the approach of signature
verification is sufficient. If you can load a module then you don't
need to fiddle with some covoluted EFI attack. Distros should include
their EFI signing key in the kernel keyring so a standard UKI passes
the test.

The eBPF approach fails from my perspective because it never actually
runs the stub code or using the EFI entry point. My interest is to
actually use the EFI entry point, not just treat it as some convoluted
zip file.

> But that still leaves the "unintentional malicious" case. Meaning,
> that someone tries to be "smart" and does weird stuff in the EFI stub

Buggy modules exist too, it is up the signer to take a position on
that, IMHO. How can you have an "out of tree stub" if the only things
loaded are signed by the kernel builder?

Regardles, Ard's suggestion to move the execution from a kthread to a
user thread could provide enough isolation to mititgate even this..

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

And you want this to be a UKI too?

I'm not sure it is so good for crash robustness to have so much more
complexity in the boot path..

Though I wonder if you can run the EFI flow when initially loading and
staging the crash kernel? Then stop at the exit boot services and wait
for a crash before jumping back into the flow.

Jason