From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Emil Tsalapatis" <emil@etsalapatis.com>
Cc: "bpf" <bpf@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Eduard" <eddyz87@gmail.com>, "Emil Tsalapatis" <etsal@meta.com>
Subject: Re: [PATCH bpf-next v3 1/9] bpf: Upgrade scalar to PTR_TO_ARENA on arena pointer addition
Date: Sat, 04 Apr 2026 14:24:30 -0400 [thread overview]
Message-ID: <DHKKX90W8XV7.116WMR48CDB2D@etsalapatis.com> (raw)
In-Reply-To: <CAADnVQ+3WG0ed8Redsn0wbZ+kwHYH-pz2G9bmzVH5MRX-kp02g@mail.gmail.com>
On Fri Apr 3, 2026 at 4:24 PM EDT, Alexei Starovoitov wrote:
> On Thu, Apr 2, 2026 at 9:27 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
>>
>> From: Emil Tsalapatis <etsal@meta.com>
>>
>> The compiler sometimes stores the result of a PTR_TO_ARENA + SCALAR
>> addition into the scalar register rather than the pointer register.
>> Handle this case by upgrading the destination scalar register to
>> PTR_TO_ARENA, matching the existing handling when the destination is
>> already PTR_TO_ARENA.
>>
>> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
>> ---
>> kernel/bpf/verifier.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 8c1cf2eb6cbb..583121b9aa7e 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -16333,6 +16333,24 @@ static int adjust_reg_min_max_vals(struct bpf_verifier_env *env,
>> bpf_alu_string[opcode >> 4]);
>> return -EACCES;
>> } else {
>> + /*
>> + * The compiler sometimes stores the result of
>> + * PTR_TO_ARENA + SCALAR addition to the scalar
>> + * register. Upgrade it to a PTR_TO_ARENA.
>> + */
>> + if (src_reg->type == PTR_TO_ARENA && opcode == BPF_ADD) {
>
> This is too specific and doesn't fully address the issue.
> How about something like this:
Makes sense, and keeps the SCALAR -> PTR_TO_ARENA in a single site. My
initial rationale for doing this just for ADD was that it was the only
two-operand operation that would make sense in this context, but that
is irrelevant to whether the instructions are safe.
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 84699a428077..457ac555da72 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -16572,11 +16572,16 @@ static int adjust_reg_min_max_vals(struct
> bpf_verifier_env *env,
> int err;
>
> dst_reg = ®s[insn->dst_reg];
> - src_reg = NULL;
> + if (BPF_SRC(insn->code) == BPF_X)
> + src_reg = ®s[insn->src_reg];
> + else
> + src_reg = NULL;
>
> - if (dst_reg->type == PTR_TO_ARENA) {
> + if (dst_reg->type == PTR_TO_ARENA || (src_reg && src_reg->type
> == PTR_TO_ARENA)) {
> struct bpf_insn_aux_data *aux = cur_aux(env);
>
> + if (dst_reg->type != PTR_TO_ARENA)
> + *dst_reg = *src_reg;
> if (BPF_CLASS(insn->code) == BPF_ALU64)
> /*
> * 32-bit operations zero upper bits automatically.
> @@ -16592,7 +16597,6 @@ static int adjust_reg_min_max_vals(struct
> bpf_verifier_env *env,
> ptr_reg = dst_reg;
>
> if (BPF_SRC(insn->code) == BPF_X) {
> - src_reg = ®s[insn->src_reg];
> if (src_reg->type != SCALAR_VALUE) {
> if (dst_reg->type != SCALAR_VALUE) {
> /* Combining two pointers by any ALU op yields
next prev parent reply other threads:[~2026-04-04 18:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 4:27 [PATCH bpf-next v3 0/9] Introduce arena library and runtime Emil Tsalapatis
2026-04-03 4:27 ` [PATCH bpf-next v3 1/9] bpf: Upgrade scalar to PTR_TO_ARENA on arena pointer addition Emil Tsalapatis
2026-04-03 5:04 ` bot+bpf-ci
2026-04-03 18:07 ` Emil Tsalapatis
2026-04-03 18:42 ` Song Liu
2026-04-03 20:24 ` Alexei Starovoitov
2026-04-04 18:24 ` Emil Tsalapatis [this message]
2026-04-03 4:27 ` [PATCH bpf-next v3 2/9] selftests/bpf: Add test for scalar/arena " Emil Tsalapatis
2026-04-03 18:43 ` Song Liu
2026-04-03 20:25 ` Alexei Starovoitov
2026-04-04 19:00 ` Emil Tsalapatis
2026-04-04 20:01 ` Alexei Starovoitov
2026-04-03 4:27 ` [PATCH bpf-next v3 3/9] selftests/bpf: Move bpf_arena_spin_lock.h to the top level Emil Tsalapatis
2026-04-03 18:44 ` Song Liu
2026-04-03 4:27 ` [PATCH bpf-next v3 4/9] selftests/bpf: Deduplicate WRITE_ONCE macro between headers Emil Tsalapatis
2026-04-03 18:44 ` Song Liu
2026-04-03 4:27 ` [PATCH bpf-next v3 5/9] selftests/bpf: Add basic libarena scaffolding Emil Tsalapatis
2026-04-03 4:27 ` [PATCH bpf-next v3 6/9] selftests/bpf: Add arena ASAN runtime to libarena Emil Tsalapatis
2026-04-03 4:27 ` [PATCH bpf-next v3 7/9] selftests/bpf: Add ASAN support for libarena selftests Emil Tsalapatis
2026-04-03 4:27 ` [PATCH bpf-next v3 8/9] selftests/bpf: Add buddy allocator for libarena Emil Tsalapatis
2026-04-03 4:27 ` [PATCH bpf-next v3 9/9] selftests/bpf: Add selftests for libarena buddy allocator Emil Tsalapatis
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=DHKKX90W8XV7.116WMR48CDB2D@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=etsal@meta.com \
--cc=memxor@gmail.com \
/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