From: Philipp Rudo <prudo@redhat.com>
To: Pingfan Liu <piliu@redhat.com>
Cc: kexec@lists.infradead.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jeremy Linton <jeremy.linton@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
Simon Horman <horms@kernel.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Viktor Malik <vmalik@redhat.com>,
Jan Hendrik Farr <kernel@jfarr.cc>, Baoquan He <bhe@redhat.com>,
Dave Young <dyoung@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
bpf@vger.kernel.org
Subject: Re: [PATCHv3 8/9] kexec: Integrate bpf light skeleton to load zboot image
Date: Wed, 25 Jun 2025 20:10:11 +0200 [thread overview]
Message-ID: <20250625201011.1eab16a5@rotkaeppchen> (raw)
In-Reply-To: <20250529041744.16458-9-piliu@redhat.com>
Hi Pingfan,
On Thu, 29 May 2025 12:17:43 +0800
Pingfan Liu <piliu@redhat.com> wrote:
> All kexec PE bpf prog should align with the interface exposed by the
> light skeleton
> four maps:
> struct bpf_map_desc ringbuf_1;
> struct bpf_map_desc ringbuf_2;
> struct bpf_map_desc ringbuf_3;
> struct bpf_map_desc ringbuf_4;
> four sections:
> struct bpf_map_desc rodata;
> struct bpf_map_desc data;
> struct bpf_map_desc bss;
> struct bpf_map_desc rodata_str1_1;
> two progs:
> SEC("fentry.s/bpf_handle_pefile")
> SEC("fentry.s/bpf_post_handle_pefile")
>
> With the above presumption, the integration consists of two parts:
> -1. Call API exposed by light skeleton from kexec
> -2. The opts_insn[] and opts_data[] are bpf-prog dependent and
> can be extracted and passed in from the user space. In the
> kexec_file_load design, a PE file has a .bpf section, which data
> content is a ELF, and the ELF contains opts_insn[] opts_data[].
> As a bonus, BPF bytecode can be placed under the protection of the
> entire PE signature.
> (Note, since opts_insn[] contains the information of the ringbuf
> size, the bpf-prog writer can change its proper size according to
> the kernel image size without modifying the kernel code)
>
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Philipp Rudo <prudo@redhat.com>
> Cc: bpf@vger.kernel.org
> To: kexec@lists.infradead.org
> ---
> kernel/Makefile | 1 +
> kernel/kexec_bpf/Makefile | 8 +
> kernel/kexec_bpf/kexec_pe_parser_bpf.lskel.h | 292 +------------------
> kernel/kexec_pe_image.c | 70 +++++
> 4 files changed, 83 insertions(+), 288 deletions(-)
>
[...]
> diff --git a/kernel/kexec_pe_image.c b/kernel/kexec_pe_image.c
> index e49d6db3c329d..f47c1e46dba97 100644
> --- a/kernel/kexec_pe_image.c
> +++ b/kernel/kexec_pe_image.c
> @@ -13,6 +13,7 @@
> #include <linux/kernel.h>
> #include <linux/vmalloc.h>
> #include <linux/kexec.h>
> +#include <linux/elf.h>
> #include <linux/pe.h>
> #include <linux/string.h>
> #include <linux/bpf.h>
> @@ -21,6 +22,7 @@
> #include <asm/image.h>
> #include <asm/memory.h>
>
> +#include "kexec_bpf/kexec_pe_parser_bpf.lskel.h"
>
> static LIST_HEAD(phase_head);
>
> @@ -163,14 +165,82 @@ static bool pe_has_bpf_section(char *file_buf, unsigned long pe_sz)
> return true;
> }
>
> +static struct kexec_pe_parser_bpf *pe_parser;
> +
> +static void *get_symbol_from_elf(const char *elf_data, size_t elf_size,
> + const char *symbol_name, unsigned int *symbol_size)
> +{
> + Elf_Ehdr *ehdr = (Elf_Ehdr *)elf_data;
> + Elf_Shdr *shdr, *symtab_shdr, *strtab_shdr, *dst_shdr;
> + Elf64_Sym *sym, *symtab = NULL;
> + char *strtab = NULL;
> + void *symbol_data = NULL;
> + int i;
> +
> + symtab_shdr = strtab_shdr = NULL;
> + if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG) != 0) {
> + pr_err("Not a valid ELF file\n");
> + goto out;
> + }
> +
> + shdr = (struct elf_shdr *)(elf_data + ehdr->e_shoff);
> + for (i = 0; i < ehdr->e_shnum; i++) {
> + if (shdr[i].sh_type == SHT_SYMTAB)
> + symtab_shdr = &shdr[i];
> + else if (shdr[i].sh_type == SHT_STRTAB && i != ehdr->e_shstrndx)
> + strtab_shdr = &shdr[i];
> + }
> +
> + if (!symtab_shdr || !strtab_shdr) {
> + pr_err("Symbol table or string table not found\n");
> + goto out;
> + }
> + symtab = (Elf64_Sym *)(elf_data + symtab_shdr->sh_offset);
> + strtab = (char *)(elf_data + strtab_shdr->sh_offset);
> + for (i = 0; i < symtab_shdr->sh_size / sizeof(Elf64_Sym); i++) {
> + sym = &symtab[i];
> + if (strcmp(&strtab[sym->st_name], symbol_name) == 0) {
> + if (sym->st_shndx >= SHN_LORESERVE)
> + return NULL; // No section data for these
> + dst_shdr = &shdr[sym->st_shndx];
> + symbol_data = (void *)(elf_data + dst_shdr->sh_offset + sym->st_value);
> + *symbol_size = symtab[i].st_size;
> + break;
> + }
> + }
> +
> +out:
> + return symbol_data;
> +}
In kernel/kexec_file.c there is kexec_purgatory_find_symbol which is
basically identical to this function. With a little bit of refractoring
it should work for both cases. I prefer using
kexec_purgatory_find_symbol as your implementation cannot handle elf
files with multiple symtab and strtab sections.
Thanks
Philipp
> +
> /* Load a ELF */
> static int arm_bpf_prog(char *bpf_elf, unsigned long sz)
> {
> + opts_data = get_symbol_from_elf(bpf_elf, sz, "opts_data", &opts_data_sz);
> + opts_insn = get_symbol_from_elf(bpf_elf, sz, "opts_insn", &opts_insn_sz);
> + if (!opts_data || !opts_insn)
> + return -1;
> + /*
> + * When light skeleton generates opts_data[] and opts_insn[], it appends a
> + * NULL terminator at the end of string
> + */
> + opts_data_sz = opts_data_sz - 1;
> + opts_insn_sz = opts_insn_sz - 1;
> +
> + pe_parser = kexec_pe_parser_bpf__open_and_load();
> + if (!pe_parser)
> + return -1;
> + kexec_pe_parser_bpf__attach(pe_parser);
> +
> return 0;
> }
>
> static void disarm_bpf_prog(void)
> {
> + kexec_pe_parser_bpf__destroy(pe_parser);
> + pe_parser = NULL;
> + opts_data = NULL;
> + opts_insn = NULL;
> }
>
> struct kexec_context {
next prev parent reply other threads:[~2025-06-25 18:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 4:17 [PATCHv3 0/9] kexec: Use BPF lskel to enable kexec to load PE format boot image Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 1/9] kexec_file: Make kexec_image_load_default global visible Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 2/9] lib/decompress: Keep decompressor when CONFIG_KEXEC_PE_IMAGE Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 3/9] bpf: Introduce bpf_copy_to_kernel() to buffer the content from bpf-prog Pingfan Liu
2025-05-29 11:48 ` kernel test robot
2025-06-25 18:10 ` Philipp Rudo
2025-05-29 4:17 ` [PATCHv3 4/9] bpf: Introduce decompressor kfunc Pingfan Liu
2025-05-29 12:31 ` kernel test robot
2025-05-29 4:17 ` [PATCHv3 5/9] kexec: Introduce kexec_pe_image to parse and load PE file Pingfan Liu
2025-06-25 18:09 ` Philipp Rudo
2025-06-30 13:45 ` Pingfan Liu
2025-07-02 9:17 ` Philipp Rudo
2025-07-03 1:17 ` Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 6/9] kexec: Integrate with the introduced bpf kfuncs Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 7/9] kexec: Introduce a bpf-prog lskel to parse PE file Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 8/9] kexec: Integrate bpf light skeleton to load zboot image Pingfan Liu
2025-06-25 18:10 ` Philipp Rudo [this message]
2025-06-30 12:40 ` Pingfan Liu
2025-05-29 4:17 ` [PATCHv3 9/9] arm64/kexec: Add PE image format support Pingfan Liu
2025-05-29 15:34 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250625201011.1eab16a5@rotkaeppchen \
--to=prudo@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ardb@kernel.org \
--cc=ast@kernel.org \
--cc=bhe@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=dyoung@redhat.com \
--cc=eddyz87@gmail.com \
--cc=horms@kernel.org \
--cc=jeremy.linton@arm.com \
--cc=john.fastabend@gmail.com \
--cc=kernel@jfarr.cc \
--cc=kexec@lists.infradead.org \
--cc=kraxel@redhat.com \
--cc=martin.lau@linux.dev \
--cc=piliu@redhat.com \
--cc=song@kernel.org \
--cc=vkuznets@redhat.com \
--cc=vmalik@redhat.com \
--cc=will@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.