From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: "Woojin Ji" <random6.xyz@gmail.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"Jiri Olsa" <jolsa@kernel.org>, "Shuah Khan" <shuah@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
"Junyoung Jang" <graypanda.inzag@gmail.com>
Subject: Re: [PATCH bpf-next v3] selftests/bpf: Add arena direct-value one-past-end reject test
Date: Thu, 11 Jun 2026 19:57:44 -0400 [thread overview]
Message-ID: <DJ6MLFYZRWEC.3N07REXZNM8HA@etsalapatis.com> (raw)
In-Reply-To: <20260610-arena-direct-value-v1-v3-1-d5f0d935ee45@gmail.com>
On Wed Jun 10, 2026 at 3:13 AM EDT, Woojin Ji wrote:
> BPF_MAP_TYPE_ARENA supports direct-value pseudo loads, but unlike array
> maps its map value_size is zero and the valid direct-value range is the
> arena mmap size, max_entries * PAGE_SIZE.
>
> Commit 3ac1a467e376 ("bpf: Fix off-by-one boundary validation in arena
> direct-value access") fixed arena_map_direct_value_addr() to reject an
> offset exactly at the end of the arena mapping. Add a regression test
> that loads a BPF_PSEUDO_MAP_VALUE with off == arena_size and verifies
> that the verifier rejects it with the expected offset in the log.
>
> This is intentionally kept as a userspace raw-instruction test. I tried
> expressing the same BPF_PSEUDO_MAP_VALUE + off == arena_size case in
> verifier_arena.c with inline assembly. The only form that produces the
> desired instruction bytes uses __imm_addr(arena), but that emits
> R_BPF_64_NODYLD32, which the libbpf/bpftool link step rejects. Other
> register, immediate, and memory constraints either fail in the BPF
> backend or lower to a normal R_BPF_64_64 load followed by an ALU add,
> which does not exercise arena_map_direct_value_addr() with the boundary
> offset in the second ldimm64 slot.
>
> A legacy test_verifier fixture can express the raw instruction directly,
> but it needs arena map creation, mmap, and fixup plumbing in the legacy
> runner. That is more intrusive than the small prog_tests raw-instruction
> test.
>
> Use the userspace raw-instruction test, following the existing selftests
> pattern used for direct map-value pseudo loads, so insns[1].imm can be
> set to arena_size precisely.
>
> Assisted-by: ChatGPT:gpt-5.5
> Signed-off-by: Woojin Ji <random6.xyz@gmail.com>
> Cc: Emil Tsalapatis <emil@etsalapatis.com>
> Cc: Junyoung Jang <graypanda.inzag@gmail.com>
Nits below, after addressing them feel free to add:
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> Changes in v3:
> - Document why verifier_arena.c inline assembly cannot express this case:
> __imm_addr emits R_BPF_64_NODYLD32, while other constraints either fail
> in the BPF backend or miss the pseudo-load boundary path.
> - Mention that natural C forms lower to a normal load plus ALU add, so they
> do not exercise arena_map_direct_value_addr() with off == arena_size.
> - Keep the userspace raw-instruction test as the least intrusive option;
> test_verifier was checked but would require legacy runner arena plumbing.
> - Link to v2: https://patch.msgid.link/20260605-arena-direct-value-v1-v2-1-a92cb281e376@gmail.com
>
> Changes in v2:
> - Explain why this uses a userspace raw-instruction test rather than a
> verifier_arena.c failure program: the test must set the second
> BPF_PSEUDO_MAP_VALUE ldimm64 immediate to arena_size exactly. For
> arena globals, libbpf derives that immediate from the arena-relative
> symbol offset, so the boundary value cannot be represented directly as
> a verifier_arena.c C-level failure program.
> - Link to v1: https://patch.msgid.link/20260603-arena-direct-value-v1-v1-1-7b31cc0a8cac@gmail.com
>
> Tested on x86_64 with tools/testing/selftests/bpf/vmtest.sh:
> $ ./test_progs -t arena_direct_value
> #2/1 arena_direct_value/one_past_end:OK
> #2 arena_direct_value:OK
> Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
> ---
> .../selftests/bpf/prog_tests/arena_direct_value.c | 73 ++++++++++++++++++++++
> 1 file changed, 73 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/arena_direct_value.c b/tools/testing/selftests/bpf/prog_tests/arena_direct_value.c
> new file mode 100644
> index 000000000000..b7760b021670
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/arena_direct_value.c
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <test_progs.h>
> +#include <bpf/bpf.h>
> +#include <errno.h>
> +#include <sys/mman.h>
> +#include <unistd.h>
> +
> +#define ARENA_PAGES 32
> +
> +static void test_arena_direct_value_one_past_end(void)
> +{
> + char log_buf[16384] = {}, expected[128];
Since the log_buf is huge, and the file has a simple test,
just move it to the BSS.
> + __u32 arena_sz = ARENA_PAGES * getpagesize();
> + struct bpf_insn insns[] = {
> + BPF_LD_IMM64_RAW(BPF_REG_1, BPF_PSEUDO_MAP_VALUE, 0),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + };
> + LIBBPF_OPTS(bpf_map_create_opts, map_opts);
> + LIBBPF_OPTS(bpf_prog_load_opts, prog_opts);
> + void *arena = MAP_FAILED;
No need to initialize this, we have not code paths where we read the
variable before it gets assigned by mmap().
> + int map_fd, prog_fd;
> +
> + map_opts.map_flags = BPF_F_MMAPABLE;
> + prog_opts.log_buf = log_buf;
> + prog_opts.log_size = sizeof(log_buf);
> + prog_opts.log_level = 1;
> +
> + map_fd = bpf_map_create(BPF_MAP_TYPE_ARENA, "arena_direct_value",
> + 0, 0, ARENA_PAGES, &map_opts);
> + if (map_fd < 0) {
> + if (errno == EOPNOTSUPP || errno == EINVAL) {
Question: Why is an EINVAL on map creation a skippable event? What failure mode
does it correspond to?
> + test__skip();
> + return;
> + }
> + ASSERT_GE(map_fd, 0, "bpf_map_create");
> + return;
> + }
> +
> + arena = mmap(NULL, arena_sz, PROT_READ | PROT_WRITE, MAP_SHARED, map_fd, 0);
> + if (!ASSERT_NEQ(arena, MAP_FAILED, "arena_mmap"))
> + goto cleanup;
> +
> + insns[0].imm = map_fd;
> + insns[1].imm = arena_sz;
> +
> + prog_fd = bpf_prog_load(BPF_PROG_TYPE_RAW_TRACEPOINT,
> + "arena_direct_value", "GPL", insns,
> + ARRAY_SIZE(insns), &prog_opts);
> + if (!ASSERT_LT(prog_fd, 0, "prog_load")) {
> + if (prog_fd >= 0)
If we only take this path if prog_fd >= 0, why the extra check
internally?
> + close(prog_fd);
> + prog_fd = -1;
No need to set this, we never use it after this.
> + goto cleanup;
> + }
> +
> + snprintf(expected, sizeof(expected),
> + "invalid access to map value pointer, value_size=0 off=%u",
> + arena_sz);
> + ASSERT_HAS_SUBSTR(log_buf, expected, "verifier_log");
> +
> +cleanup:
> + if (arena != MAP_FAILED)
> + munmap(arena, arena_sz);
> + close(map_fd);
> +}
> +
> +void test_arena_direct_value(void)
> +{
> + if (test__start_subtest("one_past_end"))
> + test_arena_direct_value_one_past_end();
> +}
>
> ---
> base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
> change-id: 20260603-arena-direct-value-v1-ef4df857b98b
>
> Best regards,
> --
> Woojin Ji <random6.xyz@gmail.com>
prev parent reply other threads:[~2026-06-11 23:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 7:13 [PATCH bpf-next v3] selftests/bpf: Add arena direct-value one-past-end reject test Woojin Ji
2026-06-11 23:57 ` Emil Tsalapatis [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=DJ6MLFYZRWEC.3N07REXZNM8HA@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=graypanda.inzag@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=random6.xyz@gmail.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--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