From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "KP Singh" <kpsingh@kernel.org>, <sashiko-reviews@lists.linux.dev>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH] bpf, libbpf: reject non-exclusive metadata maps in the signed loader
Date: Thu, 21 May 2026 03:17:03 -0700 [thread overview]
Message-ID: <DIO9ZMXP4AP8.2U06P4YWLPFV@gmail.com> (raw)
In-Reply-To: <CACYkzJ6rxGSrixr9sChFyXyu3JcjG3JmZGR5YgA0vV0WNJPs0g@mail.gmail.com>
On Tue May 19, 2026 at 8:00 PM PDT, KP Singh wrote:
> On Wed, May 20, 2026 at 1:17 AM <sashiko-bot@kernel.org> wrote:
>>
>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>> - [High] The generated BPF loader program uses a hardcoded 8-byte read (BPF_DW) to access the `excl_prog_sha` pointer field, which causes the BPF verifier to reject the loader on 32-bit architectures and silently bypasses the exclusivity check.
>
> I plan to move this to the kernel with a kfunc anyways. Any
> suggestions for the 32 bit fix (apart from an ugly union in bpf_map).
Use _bpf_md_ptr(). It's a normal pattern.
>> - [High] Branch target offset calculation is off-by-one, causing the jump target to land past the beginning of the cleanup block.
>> --
>
> Yeah this is valid:
>
> Compute the cleanup-label offset after emitting the MOV that sets the
> error code in R7. Otherwise the JMP lands one insn past cleanup_label
> and skips the first FD-close, matching the emit_check_err() pattern.
>
> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index becfda5b9025..6950443ba698 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -592,9 +592,9 @@ static void emit_signature_match(struct bpf_gen *gen)
> gen->hash_insn_offset[i] = gen->insn_cur - gen->insn_start;
> emit2(gen, BPF_LD_IMM64_RAW_FULL(BPF_REG_3, 0, 0, 0, 0, 0));
>
> - off = -(gen->insn_cur - gen->insn_start -
> gen->cleanup_label) / 8 - 1;
> + emit(gen, BPF_MOV64_IMM(BPF_REG_7, -EINVAL));
> + off = -(gen->insn_cur - gen->insn_start -
> gen->cleanup_label) / 8 - 1;
> if (is_simm16(off)) {
> - emit(gen, BPF_MOV64_IMM(BPF_REG_7, -EINVAL));
maybe fix the math instead of moving this emit ?
Also split the fix into pre-patch.
> emit(gen, BPF_JMP_REG(BPF_JNE, BPF_REG_2,
> BPF_REG_3, off));
> } else {
> gen->error = -ERANGE;
and while at it remove redundant 'emit(gen, BPF_JMP_IMM(BPF_JA, 0, 0, -1));'
pw-bot: cr
prev parent reply other threads:[~2026-05-21 10:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 21:53 [PATCH] bpf, libbpf: reject non-exclusive metadata maps in the signed loader KP Singh
2026-05-19 22:50 ` bot+bpf-ci
2026-05-19 23:17 ` sashiko-bot
2026-05-20 3:00 ` KP Singh
2026-05-21 10:17 ` Alexei Starovoitov [this message]
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=DIO9ZMXP4AP8.2U06P4YWLPFV@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=kpsingh@kernel.org \
--cc=sashiko-reviews@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox