From: sashiko-bot@kernel.org
To: chenyuan_fl@163.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] selftests/bpf: fix token tests for bpf_object__prepare() probe_loading
Date: Fri, 29 May 2026 03:39:18 +0000 [thread overview]
Message-ID: <20260529033919.2E9B41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260529031604.888137-1-chenyuan_fl@163.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch masks a libbpf bug by inappropriately expanding token privileges in tests, defeating the purpose of testing fine-grained token delegation.
- [Medium] The patch silently adds BPF_MAP_TYPE_ARRAY and BPF_PROG_LOAD permissions to test options without documenting them in the commit message.
--
commit f600b2d49f35c6ad7110d3da0ab207e0df841447
Author: Yuan Chen <chenyuan@kylinos.cn>
selftests/bpf: fix token tests for bpf_object__prepare() probe_loading
This patch modifies BPF token selftests to add SOCKET_FILTER, TRACEPOINT,
and ARRAY map permissions to various subtests. This is intended to fix test
failures caused by libbpf's internal environment probe loading.
> The bpf_object__prepare() function internally calls bpf_object__probe_loading(),
> which attempts to load SOCKET_FILTER and TRACEPOINT programs to verify the BPF
> environment. Without these permissions in the token, the probe fails and causes
> the tests to fail.
>
> Fix the following test cases by adding SOCKET_FILTER and TRACEPOINT permissions:
[Severity: Medium]
The commit message explicitly mentions adding SOCKET_FILTER and TRACEPOINT
permissions. However, the patch also adds BPF_PROG_LOAD to the obj_priv_map
test, and BPF_MAP_TYPE_ARRAY to several other tests.
Could the commit message be updated to reflect all the changes being made,
or should these undocumented changes be removed?
> diff --git a/tools/testing/selftests/bpf/prog_tests/token.c b/tools/testing/selftests/bpf/prog_tests/token.c
> index f2f5d36ae00a4..25a76e09a3c96 100644
> --- a/tools/testing/selftests/bpf/prog_tests/token.c
> +++ b/tools/testing/selftests/bpf/prog_tests/token.c
> @@ -1168,8 +1168,13 @@ void serial_test_token(void)
> }
> if (test__start_subtest("obj_priv_map")) {
> struct bpffs_opts opts = {
> - .cmds = bit(BPF_MAP_CREATE),
> + /* BPF_PROG_LOAD is needed for bpf_object__probe_loading */
> + .cmds = bit(BPF_MAP_CREATE) | bit(BPF_PROG_LOAD),
> .maps = bit(BPF_MAP_TYPE_QUEUE),
> + /* Allow SOCKET_FILTER and TRACEPOINT for bpf_object__probe_loading */
> + .progs = bit(BPF_PROG_TYPE_SOCKET_FILTER) |
> + bit(BPF_PROG_TYPE_TRACEPOINT),
> + .attachs = ~0ULL,
> };
[Severity: Medium]
By adding BPF_PROG_LOAD, SOCKET_FILTER, and TRACEPOINT here, does this
defeat the purpose of the obj_priv_map test?
This test appears specifically designed to verify that a token restricted to
only BPF_MAP_CREATE can successfully authorize map-only operations.
If bpf_object__probe_loading() causes the entire object load to abort with
-EPERM when a confined token is used, isn't this a functional bug in libbpf
rather than a test issue?
Should libbpf be fixed to handle probe -EPERM gracefully (or skip probes for
objects without programs) instead of expanding the token privileges in the
tests?
[ ... ]
> @@ -1213,9 +1232,13 @@ void serial_test_token(void)
> if (test__start_subtest("obj_priv_btf_success")) {
> struct bpffs_opts opts = {
> /* allow BTF loading */
> - .cmds = bit(BPF_BTF_LOAD) | bit(BPF_MAP_CREATE) | bit(BPF_PROG_LOAD),
> - .maps = bit(BPF_MAP_TYPE_STRUCT_OPS),
> - .progs = bit(BPF_PROG_TYPE_STRUCT_OPS),
> + .cmds = bit(BPF_BTF_LOAD) | bit(BPF_MAP_CREATE) |
> + bit(BPF_PROG_LOAD),
> + .maps = bit(BPF_MAP_TYPE_STRUCT_OPS) | bit(BPF_MAP_TYPE_ARRAY),
> + /* Allow SOCKET_FILTER and TRACEPOINT for bpf_object__probe_loading */
> + .progs = bit(BPF_PROG_TYPE_STRUCT_OPS) |
> + bit(BPF_PROG_TYPE_SOCKET_FILTER) |
> + bit(BPF_PROG_TYPE_TRACEPOINT),
> .attachs = ~0ULL,
> };
[Severity: Medium]
Is there a specific reason BPF_MAP_TYPE_ARRAY is being added to the
maps allowance here? It seems unrelated to the probe loading fix described
in the commit message.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260529031604.888137-1-chenyuan_fl@163.com?part=1
next prev parent reply other threads:[~2026-05-29 3:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 3:16 [PATCH] selftests/bpf: fix token tests for bpf_object__prepare() probe_loading chenyuan_fl
2026-05-29 3:39 ` sashiko-bot [this message]
2026-05-29 3:57 ` bot+bpf-ci
2026-06-04 3:10 ` [PATCH bpf-next v2 0/3] libbpf: fix implicit BPF token handling in loading and feature probes chenyuan_fl
2026-06-04 3:10 ` [PATCH bpf-next v2 1/3] libbpf: Skip bpf_object__probe_loading() when BPF token is in use chenyuan_fl
2026-06-04 4:05 ` bot+bpf-ci
2026-06-04 11:16 ` Mykyta Yatsenko
2026-06-08 18:17 ` Andrii Nakryiko
2026-06-09 13:11 ` [PATCH bpf] " chenyuan_fl
2026-06-09 13:35 ` Mykyta Yatsenko
2026-06-09 13:42 ` bot+bpf-ci
2026-06-04 3:10 ` [PATCH bpf-next v2 2/3] selftests/bpf: Add ARRAY map type to token tests that use struct_ops global data chenyuan_fl
2026-06-04 3:25 ` sashiko-bot
2026-06-08 18:14 ` Andrii Nakryiko
2026-06-04 3:10 ` [PATCH bpf-next v2 3/3] libbpf: fix feature probe failures for implicit BPF tokens chenyuan_fl
2026-06-04 3:27 ` sashiko-bot
2026-06-04 4:05 ` bot+bpf-ci
2026-06-04 14:40 ` Mykyta Yatsenko
2026-06-08 18:18 ` Andrii Nakryiko
2026-06-10 14:50 ` [PATCH bpf-next v3 0/2] libbpf: fix implicit BPF token feature probe failures chenyuan_fl
2026-06-10 14:50 ` [PATCH bpf-next v3 1/2] libbpf: Skip bpf_object__probe_loading() when BPF token is in use chenyuan_fl
2026-06-10 16:30 ` bot+bpf-ci
2026-06-10 14:50 ` [PATCH bpf-next v3 2/2] libbpf: fetch probeable prog type from token for feature probes chenyuan_fl
2026-06-10 15:04 ` sashiko-bot
2026-06-10 16:30 ` bot+bpf-ci
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=20260529033919.2E9B41F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan_fl@163.com \
--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