[PATCHv7 11/13] tools/kexec: Introduce a bpf-prog to handle zboot image

[bot+bpf-ci at kernel.org]

> diff --git a/tools/kexec/Makefile b/tools/kexec/Makefile
> --- /dev/null
> +++ b/tools/kexec/Makefile

[ ... ]

> +ifeq ($(ARCH),$(filter $(ARCH),arm64 riscv loongarch))
> +	EFI_IMAGE := $(srctree)/arch/$(ARCH)/boot/vmlinuz.efi
> +	KERNEL_IMAGE := $(srctree)/arch/$(ARCH)/boot/vmlinux.bin
> +else
> +	@echo "Unsupported architecture: $(ARCH)"
> +	@exit 1
> +endif

The else branch uses recipe syntax (@echo, @exit) at top-level
Makefile scope, outside of any rule.  On unsupported architectures
this would produce a confusing GNU Make parse error rather than
the intended message.  Should this use $(error ...) instead?

> +zboot: $(HEADERS) $(call BPF_ARTIFACTS,zboot) build_zboot_image

There is no rule or file for the build_zboot_image prerequisite
in this Makefile.  Will this cause "make zboot" to fail with
"No rule to make target 'build_zboot_image'"?

[ ... ]

> diff --git a/tools/kexec/zboot_parser_bpf.c b/tools/kexec/zboot_parser_bpf.c
> --- /dev/null
> +++ b/tools/kexec/zboot_parser_bpf.c

[ ... ]

> +/* ringbuf 2,3,4 are useless */
> +#define MIN_BUF_SIZE    1
> +#define MAX_RECORD_SIZE (IMAGE_SIZE + 40960)
> +#define RINGBUF1_SIZE   IMAGE_SIZE_POWER2_ALIGN
> +#define RINGBUF2_SIZE   MIN_BUF_SIZE
> +#define RINGBUF3_SIZE   MIN_BUF_SIZE
> +#define RINGBUF4_SIZE   MIN_BUF_SIZE

ringbuf_map_alloc() in kernel/bpf/ringbuf.c requires max_entries
to be both power-of-2 and PAGE_ALIGNED.  With MIN_BUF_SIZE set
to 1, ringbufs 2/3/4 will fail map creation with -EINVAL since
PAGE_ALIGNED(1) is false.  The minimum valid size would be
PAGE_SIZE (typically 4096).  Would the BPF program fail to load
because of this?

[ ... ]

> +static int fill_cmd(char *buf, __u16 cmd, __u16 subcmd,
> +				    const char *src, __u32 data_len)
> +{
> +	struct cmd_hdr *hdr;
> +	char *payload;
> +
> +	hdr              = (struct cmd_hdr *)buf;
> +	hdr->cmd         = cmd;
> +	hdr->subcmd      = subcmd;
> +	hdr->payload_len = data_len;
> +	hdr->num_chunks  = 0;

The struct cmd_hdr (in kernel/kexec_bpf_loader.c) also has a
pipeline_flag field at offset 3:

    struct cmd_hdr {
        uint16_t cmd;
        uint8_t subcmd;
        uint8_t pipeline_flag;
        uint32_t payload_len;
        uint16_t num_chunks;
    };

This field is not initialized here, and bpf_ringbuf_reserve() does
not zero the returned memory.  The kernel's kexec_buff_parser()
reads this field:

    fill_pipeline = cmd->pipeline_flag & KEXEC_BPF_PIPELINE_FILL;

If the garbage byte happens to have bit 0x1 set, this would
trigger unintended pipeline fill behavior, causing extra
allocations and copies into next_parsing_buf[].  Should
pipeline_flag be explicitly zeroed?

[ ... ]

> +SEC("fentry.s/kexec_image_parser_anchor")
> +int BPF_PROG(parse_zboot, struct kexec_context *context, unsigned long parser_id)
> +{
> +	kexec_sig_enforced sig_mode;

[ ... ]

> +	sig_mode = BPF_CORE_READ(context, sig_mode);

The type kexec_sig_enforced does not appear to exist as a type
(enum, typedef, or struct) anywhere in the kernel sources.  The
only related symbol is the function set_kexec_sig_enforced().
Similarly, struct kexec_context (in kernel/kexec_bpf_loader.c)
has no sig_mode field.

Since the BPF program includes vmlinux.h generated from the
kernel's BTF, it would fail to compile without this type, and
the BPF_CORE_READ would fail CO-RE relocation without the
struct field.  Are these expected to be added by a patch not
yet in this series?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23393379437