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: Mon, 15 Dec 2025 12:19:00 -0800	[thread overview]
Message-ID: <0720a98e6a73ee6298d73b2c64a08f47a4337007.camel@gmail.com> (raw)
In-Reply-To: <20251215161313.10120-3-emil@etsalapatis.com>

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

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?

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

[-- Attachment #2: disable-range-checks.patch --]
[-- Type: text/x-patch, Size: 1704 bytes --]

diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
index 1074ac4459f2..cf38388bb094 100644
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@ -388,8 +388,10 @@ static int arena_map_direct_value_addr(const struct bpf_map *map, u64 *imm, u32
 {
 	struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
 
-	if ((u64)off > arena->user_vm_end - arena->user_vm_start)
-		return -ERANGE;
+	/*
+	 * if ((u64)off > arena->user_vm_end - arena->user_vm_start)
+	 * 	return -ERANGE;
+	 */
 	*imm = (unsigned long)arena->user_vm_start;
 	return 0;
 }
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 1eeb31c5b317..e13c58f2e3b8 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -193,8 +193,10 @@ static int array_map_direct_value_addr(const struct bpf_map *map, u64 *imm,
 
 	if (map->max_entries != 1)
 		return -ENOTSUPP;
-	if (off >= map->value_size)
-		return -EINVAL;
+	/*
+	 * if (off >= map->value_size)
+	 * 	return -EINVAL;
+	 */
 
 	*imm = (unsigned long)array->value;
 	return 0;
diff --git a/kernel/bpf/bpf_insn_array.c b/kernel/bpf/bpf_insn_array.c
index c96630cb75bf..aa4b71365541 100644
--- a/kernel/bpf/bpf_insn_array.c
+++ b/kernel/bpf/bpf_insn_array.c
@@ -121,9 +121,11 @@ static int insn_array_map_direct_value_addr(const struct bpf_map *map, u64 *imm,
 {
 	struct bpf_insn_array *insn_array = cast_insn_array(map);
 
-	if ((off % sizeof(long)) != 0 ||
-	    (off / sizeof(long)) >= map->max_entries)
-		return -EINVAL;
+	/*
+	 * if ((off % sizeof(long)) != 0 ||
+	 *     (off / sizeof(long)) >= map->max_entries)
+	 * 	return -EINVAL;
+	 */
 
 	/* from BPF's point of view, this map is a jump table */
 	*imm = (unsigned long)insn_array->ips + off;

  reply	other threads:[~2025-12-15 20:19 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 [this message]
2025-12-16 17:25     ` Emil Tsalapatis
2025-12-16 20:13       ` Eduard Zingerman
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=0720a98e6a73ee6298d73b2c64a08f47a4337007.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