BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Emil Tsalapatis <emil@etsalapatis.com>, bpf@vger.kernel.org
Cc: andrii@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	 john.fastabend@gmail.com, memxor@gmail.com,
	yonghong.song@linux.dev
Subject: Re: [PATCH v3 2/5] bpf/verifier: do not limit maximum direct offset into arena map
Date: Tue, 16 Dec 2025 12:13:20 -0800	[thread overview]
Message-ID: <4edb0de3c4eb13d276df8741c663e398ddde5708.camel@gmail.com> (raw)
In-Reply-To: <DEZTEJOJ7WF2.1VFDHK28XKO4A@etsalapatis.com>

On Tue, 2025-12-16 at 12:25 -0500, Emil Tsalapatis wrote:
> On Mon Dec 15, 2025 at 3:19 PM EST, Eduard Zingerman wrote:
> > On Mon, 2025-12-15 at 11:13 -0500, Emil Tsalapatis wrote:
> > > The verifier currently limits direct offsets into a map to 512MiB
> > > to avoid overflow during pointer arithmetic. However, this prevents
> > > arena maps from using direct addressing instructions to access data
> > > at the end of > 512MiB arena maps. This is necessary when moving
> > > arena globals to the end of the arena instead of the front.
> > >
> > > Refactor the verifier code to remove the offset calculation during
> > > direct value access calculations. This is possible because the only
> > > two map types that implement .map_direct_value_addr() are arrays and
> > > arenas, and they both do their own internal checks to ensure the
> > > offset is within bounds.
> >
> > Nit: instruction array map also implements it (bpf_insn_array.c).
> >
> > >
> > > Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> > > ---
> >
> > I double checked implementations for all 3 map types and confirm that
> > the above is correct. Also, I commented out the range checks in kernel
> > implementations (as in the attached patch), and no tests seem to fail.
> > Do we need to extend selftests?
>
> I forgot to address a couple selftest errors from this patch in this version,
> but after fixing them for v4 and applying the attached patch I am getting a
> couple failures - direct map access tests #332, #334, #336, #337, #338, #345.

Uh-oh, sorry, I forgot about test_verifier binary.

> #332 (write test 7) is an unexpected load success, while the rest are about a
> mismatch in the error message. Maybe the test wasn't being marked as an
> unexpected success because I hadn't fixed it up?

For me it shows:

  #332/p direct map access, write test 7 FAIL
  Unexpected verifier log!
  EXP: direct value offset of 4294967295 is not allowed
  RES:
  FAIL
  Unexpected error message!
          EXP: direct value offset of 4294967295 is not allowed
          RES: invalid access to map value pointer, value_size=48 off=4294967295

So, seem to be an expected behavior given your changes?

  reply	other threads:[~2025-12-16 20:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15 16:13 [PATCH v3 0/5] libbpf: move arena variables out of the zero page Emil Tsalapatis
2025-12-15 16:13 ` [PATCH v3 1/5] selftests/bpf: explicitly account for globals in verifier_arena_large Emil Tsalapatis
2025-12-15 16:13 ` [PATCH v3 2/5] bpf/verifier: do not limit maximum direct offset into arena map Emil Tsalapatis
2025-12-15 20:19   ` Eduard Zingerman
2025-12-16 17:25     ` Emil Tsalapatis
2025-12-16 20:13       ` Eduard Zingerman [this message]
2025-12-16 21:48         ` Emil Tsalapatis
2025-12-15 16:13 ` [PATCH v3 3/5] libbpf: turn relo_core->sym_off unsigned Emil Tsalapatis
2025-12-15 16:37   ` bot+bpf-ci
2025-12-15 17:08     ` Emil Tsalapatis
2025-12-15 20:05   ` Eduard Zingerman
2025-12-15 16:13 ` [PATCH v3 4/5] libbpf: move arena globals to the end of the arena Emil Tsalapatis
2025-12-15 21:12   ` Eduard Zingerman
2025-12-15 16:13 ` [PATCH v3 5/5] selftests/bpf: add tests for the arena offset of globals Emil Tsalapatis
2025-12-15 21:26   ` Eduard Zingerman
2025-12-16  2:28     ` 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=4edb0de3c4eb13d276df8741c663e398ddde5708.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=emil@etsalapatis.com \
    --cc=john.fastabend@gmail.com \
    --cc=memxor@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox