Re: [PATCHv6 04/13] kexec_file: Use bpf-prog to decompose image

From: Pingfan Liu

Date: Thu Feb 26 2026 - 21:40:44 EST


On Thu, Feb 26, 2026 at 9:37 PM Philipp Rudo <prudo@xxxxxxxxxx> wrote:
>
> Hi Pingfan,
>
> On Mon, 19 Jan 2026 11:24:15 +0800
> Pingfan Liu <piliu@xxxxxxxxxx> wrote:
>
> [...]
>
> > diff --git a/kernel/kexec_bpf_loader.c b/kernel/kexec_bpf_loader.c
> > new file mode 100644
> > index 0000000000000..dc59e1389da94
> > --- /dev/null
> > +++ b/kernel/kexec_bpf_loader.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Kexec image bpf section helpers
> > + *
> > + * Copyright (C) 2025, 2026 Red Hat, Inc
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file(Image): " fmt
> > +
> > +#include <linux/err.h>
> > +#include <linux/errno.h>
> > +#include <linux/list.h>
> > +#include <linux/kernel.h>
> > +#include <linux/vmalloc.h>
> > +#include <linux/kexec.h>
> > +#include <linux/elf.h>
> > +#include <linux/string.h>
> > +#include <linux/bpf.h>
> > +#include <linux/filter.h>
> > +#include <asm/byteorder.h>
> > +#include <asm/image.h>
> > +#include <asm/memory.h>
> > +#include "kexec_internal.h"
> > +
> > +/* Load a ELF */
> > +static int arm_bpf_prog(char *bpf_elf, unsigned long sz)
> > +{
> > + return 0;
> > +}
> > +
> > +static void disarm_bpf_prog(void)
> > +{
> > +}
> > +
> > +struct kexec_context {
> > + bool kdump;
> > + char *kernel;
> > + int kernel_sz;
> > + char *initrd;
> > + int initrd_sz;
> > + char *cmdline;
> > + int cmdline_sz;
> > +};
> > +
> > +void kexec_image_parser_anchor(struct kexec_context *context,
> > + unsigned long parser_id);
> > +
> > +/*
> > + * optimize("O0") prevents inline, compiler constant propagation
> > + *
> > + * Let bpf be the program context pointer so that it will not be spilled into
> > + * stack.
> > + */
> > +__attribute__((used, optimize("O0"))) void kexec_image_parser_anchor(
> > + struct kexec_context *context,
> > + unsigned long parser_id)
> > +{
> > + /*
> > + * To prevent linker from Identical Code Folding (ICF) with kexec_image_parser_anchor,
> > + * making them have different code.
> > + */
> > + volatile int dummy = 0;
> > +
> > + dummy += 1;
> > +}
> > +
> > +
> > +BTF_KFUNCS_START(kexec_modify_return_ids)
> > +BTF_ID_FLAGS(func, kexec_image_parser_anchor, KF_SLEEPABLE)
> > +BTF_KFUNCS_END(kexec_modify_return_ids)
> > +
> > +static const struct btf_kfunc_id_set kexec_modify_return_set = {
> > + .owner = THIS_MODULE,
> > + .set = &kexec_modify_return_ids,
> > +};
> > +
> > +static int __init kexec_bpf_prog_run_init(void)
> > +{
> > + return register_btf_fmodret_id_set(&kexec_modify_return_set);
> > +}
> > +late_initcall(kexec_bpf_prog_run_init);
> > +
> > +static int kexec_buff_parser(struct bpf_parser_context *parser)
> > +{
> > + return 0;
> > +}
> > +
> > +/* At present, only PE format file with .bpf section is supported */
> > +#define file_has_bpf_section pe_has_bpf_section
> > +#define file_get_section pe_get_section
> > +
> > +int decompose_kexec_image(struct kimage *image, int extended_fd)
> > +{
> > + struct kexec_context context = { 0 };
> > + struct bpf_parser_context *bpf;
> > + unsigned long kernel_sz, bpf_sz;
> > + char *kernel_start, *bpf_start;
> > + int ret = 0;
> > +
> > + if (image->type != KEXEC_TYPE_CRASH)
> > + context.kdump = false;
> > + else
> > + context.kdump = true;
> > +
> > + kernel_start = image->kernel_buf;
> > + kernel_sz = image->kernel_buf_len;
> > +
> > + while (file_has_bpf_section(kernel_start, kernel_sz)) {
> > +
> > + bpf = alloc_bpf_parser_context(kexec_buff_parser, &context);
> > + if (!bpf)
> > + return -ENOMEM;
> > + file_get_section((const char *)kernel_start, ".bpf", &bpf_start, &bpf_sz);
> > + if (!!bpf_sz) {
> > + /* load and attach bpf-prog */
> > + ret = arm_bpf_prog(bpf_start, bpf_sz);
> > + if (ret) {
> > + put_bpf_parser_context(bpf);
> > + pr_err("Fail to load .bpf section\n");
> > + goto err;
> > + }
> > + }
>
> I'm not sure this works as intended. In case a .bpf section exists but
> bpf_sz is 0, the function will skip arming the bpf-prog but still
> continue. That doesn't look right to me. IIUC a zero size bpf-prog
> should be an error. Or am I missing something?
>

Yes, you are right. It's better to treat a zero bpf_sz as an invalid format.

Thanks,

Pingfan