From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: <sashiko-reviews@lists.linux.dev>,
"Emil Tsalapatis" <emil@etsalapatis.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 3/5] bpf: Allow subprogs to return arena pointers
Date: Mon, 01 Jun 2026 01:09:41 -0400 [thread overview]
Message-ID: <DIXGCACGWUVB.15OD5ER214U3S@etsalapatis.com> (raw)
In-Reply-To: <20260530045438.5CD9F1F00893@smtp.kernel.org>
On Sat May 30, 2026 at 12:54 AM EDT, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Global subprograms returning arena pointers have their return value unconditionally marked as a scalar at the call site.
> - [Medium] The verifier bypasses BTF type enforcement for global subprogram return values.
> - [Low] The error message logged when a global function has an invalid return type is outdated and confusing.
> --
>
> commit 0192bc82392a7d1bde4b6ab66bef8ece2f90c7cf
> Author: Emil Tsalapatis <emil@etsalapatis.com>
>
> bpf: Allow subprogs to return arena pointers
>
> This patch expands the verifier to permit returning an arena pointer to the
> caller from a subprogram. The main subprog is still not allowed to return
> an arena pointer.
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index c6a930aca67ec..7a8101879f84d 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>
> [ ... ]
>
>> @@ -7963,17 +7993,15 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> [ ... ]
>> - if (!btf_type_is_void(t) && !btf_type_is_int(t) && !btf_is_any_enum(t)) {
>> - if (!is_global)
>> - return -EINVAL;
>> - bpf_log(log,
>> - "Global function %s() return value not void or scalar. "
>> - "Only those are supported.\n",
>> - tname);
>> +
>> + err = btf_validate_return_type(env, btf, t, subprog);
>> + if (err) {
>> + if (is_global) {
>> + bpf_log(log,
>> + "Global function %s() return value not void or scalar. "
>> + "Only those are supported.\n",
>> + tname);
>> + }
>> return -EINVAL;
>> }
>
> [Severity: Low]
> Since arena pointers are now supported, should this error message be
> updated to avoid confusing users? It still states that only void or
> scalars are supported.
>
Not necessary imo, the error is there for when things go wrong. Nobody's
going to read it and go "I should change my program to not return arena
pointers." If they're inspecting the verifier source, they have the
logic for allowing __arena tagged pointers in front of them.
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index c8d980fdd7099..64d7954e93ea7 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -9375,7 +9375,7 @@ static int check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>> clear_caller_saved_regs(env, caller->regs);
>> invalidate_outgoing_stack_args(env, cur_func(env));
>>
>> - /* All non-void global functions return a 64-bit SCALAR_VALUE. */
>> + /* All non-void global functions return a 64-bit SCALAR_VALUE or PTR_TO_ARENA. */
>> if (!subprog_returns_void(env, subprog)) {
>> mark_reg_unknown(env, caller->regs, BPF_REG_0);
>> caller->regs[BPF_REG_0].subreg_def = DEF_NOT_SUBREG;
>> }
>
> [Severity: High]
> Does this unconditionally mark the caller's R0 register as a SCALAR_VALUE?
>
> When returning from a global subprogram, mark_reg_unknown() clears the
> register state. If the subprogram actually returned an arena pointer,
> it seems the caller will receive an untracked scalar instead. Any attempt
> by the caller to dereference it would then fail verification.
>
> Should we inspect the subprogram's BTF return type here to dynamically
> set caller->regs[BPF_REG_0].type = PTR_TO_ARENA when appropriate?
I will change the comment back because it's actually inaccurate.
(Somewhat confusingly) we're returning arena pointers but not
PTR_TO_ARENA - the pointer returned is a SCALAR_VALUE. THe bytecode will
turn this into a PTR_TO_ARENA with an address space cast just fine.
>
>> @@ -16645,6 +16645,10 @@ static int check_global_subprog_return_code(struct bpf_verifier_env *env)
>> if (err)
>> return err;
>>
>> + /* Pointers to arena are safe to pass between subprograms. */
>> + if (is_arena_reg(env, BPF_REG_0))
>> + return 0;
>> +
>> if (is_pointer_value(env, BPF_REG_0)) {
>> verbose(env, "R%d leaks addr as return value\n", BPF_REG_0);
>> return -EACCES;
>
> [Severity: Medium]
> Does this bypass BTF type enforcement for the return value?
>
> By just checking if R0 is an arena register and returning 0, a global
> subprogram declared in BTF as returning an int could successfully return
> a PTR_TO_ARENA. Conversely, a subprogram declared as returning an arena
> pointer could successfully return a SCALAR_VALUE, since the fallback scalar
> check later in the function would allow it.
>
> Should we verify that the actual register type matches the subprogram's
> BTF return type signature?
Same thing, fixing the comment should make this clear that this is a
non-concern.
next prev parent reply other threads:[~2026-06-01 5:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 0:22 [PATCH bpf-next v2 0/5] bpf: Minimize annotations for arena programs Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 1/5] selftests/bpf: libarena: Add "arena" BTF type tag to __arena qualifier Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments Emil Tsalapatis
2026-05-30 0:59 ` sashiko-bot
2026-06-01 5:12 ` Emil Tsalapatis
2026-06-01 18:37 ` Eduard Zingerman
2026-06-01 19:13 ` Emil Tsalapatis
2026-06-01 19:14 ` Eduard Zingerman
2026-05-30 0:22 ` [PATCH bpf-next v2 3/5] bpf: Allow subprogs to return arena pointers Emil Tsalapatis
2026-05-30 4:54 ` sashiko-bot
2026-06-01 5:09 ` Emil Tsalapatis [this message]
2026-06-01 19:01 ` Eduard Zingerman
2026-06-02 0:06 ` Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 4/5] selftests/bpf: Remove __arg_arena from the codebase Emil Tsalapatis
2026-05-30 5:03 ` sashiko-bot
2026-05-31 5:18 ` Alexei Starovoitov
2026-06-01 5:03 ` Emil Tsalapatis
2026-06-01 19:06 ` Eduard Zingerman
2026-05-30 0:22 ` [PATCH bpf-next v2 5/5] selftests/bpf: libarena: Directly return arena pointers from functions Emil Tsalapatis
2026-06-01 19:07 ` Eduard Zingerman
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=DIXGCACGWUVB.15OD5ER214U3S@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=bpf@vger.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