BPF List
 help / color / mirror / Atom feed
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

  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