From: bot+bpf-ci@kernel.org
To: wanjay@amazon.com,bpf@vger.kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com
Cc: ihor.solodrai@linux.dev,almagui@kernel.org,martin.lau@linux.dev,yonghong.song@linux.dev,jolsa@kernel.org,rostedt@goodmis.org,mhiramat@kernel.org,mathieu.desnoyers@efficios.com,linux-trace-kernel@vger.kernel.org,nathan@kernel.org,nsc@kernel.org,linux-kbuild@vger.kernel.org,arnd@arndb.de,linux-arch@vger.kernel.org,x86@kernel.org,linux-doc@vger.kernel.org,linux-kernel@vger.kernel.org,abuehaze@amazon.com,doebel@amazon.de,mpohlack@amazon.de,jay.wang.upstream@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 02/13] bpf: fetch the vmlinux BTF where kernel types enter a program
Date: Sat, 31 Oct 2026 13:55:40 +0000 (UTC) [thread overview]
Message-ID: <5b30c8da1e5fa12691926f41a2a845d2a6f47ce33611c249c79350e67f4e636e@mail.kernel.org> (raw)
In-Reply-To: <20261031130959.23472-3-wanjay@amazon.com>
[-- Attachment #1: Type: text/plain, Size: 7735 bytes --]
> bpf: fetch the vmlinux BTF where kernel types enter a program
TL;DR:
- check_ptr_to_map_access(): without BTF, the map_ptr error now names the map
type, not the missing BTF, and the new !btf branch looks unreachable
- Co-developed-by is followed by a placeholder, not a Signed-off-by (commit
message)
> bpf: fetch the vmlinux BTF where kernel types enter a program
>
> bpf_check() fetches the vmlinux BTF up front for every program, whether
> the program uses kernel types or not. That is free today because the
> BTF is parsed at boot anyway. Once it can be parsed on first use
> (CONFIG_DEBUG_INFO_BTF_LAZY, later in this series), it would make every
> program load pay for parsing 5-7 MB of BTF, including the socket filters
> systemd loads at boot.
> Drop the up-front fetch and fetch where kernel types enter the verifier
> state instead:
> - bpf_add_kfunc_call(), for the first kfunc call of a program;
> - check_ptr_to_map_access(), for map_ptr field access;
> - check_pseudo_btf_id(), for ldimm64 of a kernel variable (ksym);
> - check_helper_call(), for helpers whose prototype takes
> ARG_PTR_TO_BTF_ID or returns RET_PTR_TO_BTF_ID, and for
> bpf_snprintf_btf() and bpf_seq_printf_btf(), which take a kernel
> type id inside struct btf_ptr (helper_uses_vmlinux_btf()).
> The other ways in already fetch the BTF themselves: attach_btf in
> bpf_prog_load(), struct_ops map creation, CO-RE candidate lookup,
> bpf_find_btf_id(), btf_prepare_func_args() for kernel-typed arguments
> and the kernel context type lookups. The remaining reads of the
> btf_vmlinux global in the verifier are on paths dominated by one of
> these fetches. A program that uses none of them, such as a socket
> filter, does not need the vmlinux BTF any more, and verifies the same
> whether or not it has been parsed.
> Four related changes keep it that way:
> - The "in-kernel BTF is malformed" check in bpf_check() read the
> global right after the up-front fetch. Without the fetch it would
> pass or fail depending on whether something else had parsed the BTF
> before, so drop it; every fetch point reports a missing BTF itself
> and passes on an error of the parse, as that check did.
> - check_ptr_to_map_access() checks allow_ptr_leaks before it fetches
> the BTF, and bpf_prog_load() falls back to the vmlinux BTF for an
> attach_btf_id only with CAP_BPF, which all program types that take
> one need, so that an unprivileged load cannot make the kernel parse
> it only to be refused. The map_ptr permission error can then not
> name the map's struct any more and says "map_ptr access is allowed
> only to CAP_PERFMON and CAP_SYS_ADMIN". A ksym, which unprivileged
> programs may use, still parses it.
> - Add bpf_peek_btf_vmlinux(), which returns the vmlinux BTF only if it
> is parsed already, and use it in bpf_btf_printf_prepare(). The BTF
> printf helpers run in program context, which may be atomic, and the
> verifier has fetched the BTF for every program that calls them.
> - is_kfunc_dynptr_write(), reached from the argument checks that
> helpers and kfuncs share, compared meta->btf with the global, which
> a helper's NULL matches while the global is NULL. Check that the
> call is a kfunc first, as the other kfunc predicates there do.
> Helpers taking ARG_PTR_TO_BTF_ID_SOCK_COMMON are left out on purpose:
> they take sockets without BTF types too, the shared argument check reads
> the global only for a PTR_TO_BTF_ID register, and every source of such
> a register fetched the BTF.
> No functional change with CONFIG_DEBUG_INFO_BTF=y, where kfunc
> registrations at boot parse the BTF, other than that error message and
> that, if the vmlinux BTF fails to parse (a broken toolchain), programs
> that use no kernel types now load instead of failing. Without BTF the
> new helper check is compiled out and the existing error paths are
> unchanged.
> Co-developed-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> TODO-NEEDS-IHOR: Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Signed-off-by: Jay Wang <wanjay@amazon.com>
This isn't a bug, but the Co-developed-by: tag is followed by a placeholder
line, "TODO-NEEDS-IHOR: Signed-off-by: Ihor Solodrai
<ihor.solodrai@linux.dev>", rather than a real Signed-off-by: line.
Documentation/process/submitting-patches.rst asks for a Co-developed-by: to
be immediately followed by that co-author's Signed-off-by:. Should the
placeholder be replaced with the real tag before this is applied?
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1b6c0674ff6a..18b2bd009d58 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -6867,30 +6883,33 @@ static int check_ptr_to_map_access(struct bpf_verifier_env *env,
> enum bpf_type_flag flag = 0;
> const struct btf_type *t;
> const char *tname;
> + struct btf *btf;
> u32 btf_id;
> int ret;
>
> - if (!btf_vmlinux) {
> - verbose(env, "map_ptr access not supported without CONFIG_DEBUG_INFO_BTF\n");
> - return -ENOTSUPP;
> - }
> -
> if (!map->ops->map_btf_id || !*map->ops->map_btf_id) {
> verbose(env, "map_ptr access not supported for map type %d\n",
> map->map_type);
> return -ENOTSUPP;
> }
>
> - t = btf_type_by_id(btf_vmlinux, *map->ops->map_btf_id);
> - tname = btf_name_by_offset(btf_vmlinux, t->name_off);
> -
> + /* before the BTF fetch: unprivileged loads must not parse it */
> if (!env->allow_ptr_leaks) {
> - verbose(env,
> - "'struct %s' access is allowed only to CAP_PERFMON and CAP_SYS_ADMIN\n",
> - tname);
> + verbose(env, "map_ptr access is allowed only to CAP_PERFMON and CAP_SYS_ADMIN\n");
> return -EPERM;
> }
>
> + btf = bpf_get_btf_vmlinux();
> + if (IS_ERR(btf))
> + return vmlinux_btf_err(env, btf);
> + if (!btf) {
> + verbose(env, "map_ptr access not supported without CONFIG_DEBUG_INFO_BTF\n");
> + return -ENOTSUPP;
> + }
> +
> + t = btf_type_by_id(btf, *map->ops->map_btf_id);
> + tname = btf_name_by_offset(btf, t->name_off);
> +
> if (off < 0) {
Can the new "if (!btf)" branch ever be reached?
Without CONFIG_DEBUG_INFO_BTF, every map type's .map_btf_id points at a
zero-filled array:
include/linux/btf_ids.h:
#define BTF_ID_LIST_SINGLE(name, prefix, typename) static u32 __maybe_unused name[1];
so "!*map->ops->map_btf_id" is true for every map, and the function returns
at the first check with "map_ptr access not supported for map type %d".
With CONFIG_DEBUG_INFO_BTF=y, bpf_get_btf_vmlinux() returns either a BTF or
an ERR_PTR, never NULL, so the branch is unreachable in that configuration
too.
Before this patch, "if (!btf_vmlinux)" was the first test. On a kernel
without BTF, a privileged program doing "r0 = *(u32 *)(map_ptr + off)" was
told:
map_ptr access not supported without CONFIG_DEBUG_INFO_BTF
It is now told, for example:
map_ptr access not supported for map type 1
That message points at the map type rather than at the missing BTF. The
errno (-ENOTSUPP) is unchanged.
This also looks at odds with the commit message statement "Without BTF the
new helper check is compiled out and the existing error paths are
unchanged."
Would an early IS_ENABLED(CONFIG_DEBUG_INFO_BTF) test with the old message,
placed before the map_btf_id check, be a way to keep the old diagnostic? It
would not fetch or parse anything, so the allow_ptr_leaks-before-fetch
ordering would stay as is.
No later commit in the series changes check_ptr_to_map_access().
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/41205212136
next prev parent reply other threads:[~2026-10-31 13:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 13:09 [PATCH bpf-next 00/13] bpf: keep the vmlinux BTF compressed until first use (CONFIG_DEBUG_INFO_BTF_LAZY) to save ~6 MB memory Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 01/13] bpf: match program context types by name without vmlinux BTF Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 02/13] bpf: fetch the vmlinux BTF where kernel types enter a program Jay Wang
2026-10-31 13:55 ` bot+bpf-ci [this message]
2026-10-31 13:09 ` [PATCH bpf-next 03/13] bpf: check CAP_SYS_ADMIN before looking up bpffs delegation names Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 17:03 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 04/13] bpf: move bpf_get_btf_vmlinux() to btf.c Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 05/13] bpf: let btf_parse_module() adopt the caller's copy of the module BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 06/13] bpf: look up the struct_ops common value type in the given BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 07/13] bpf: parse the vmlinux BTF before taking cand_cache_mutex Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 08/13] tracing: parse the vmlinux BTF when BTF-typed output is enabled Jay Wang
2026-10-31 13:43 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 09/13] bpf: keep the vmlinux BTF zstd-compressed in the kernel image Jay Wang
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 13:09 ` [PATCH bpf-next 10/13] bpf: defer kfunc and struct_ops registrations until first BTF use Jay Wang
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 17:07 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 11/13] bpf: keep module BTF until the vmlinux BTF is parsed Jay Wang
2026-10-31 13:55 ` bot+bpf-ci
2026-10-31 17:10 ` Alexei Starovoitov
2026-10-31 13:09 ` [PATCH bpf-next 12/13] selftests/bpf: keep ksyms and linked_vars working without __start_BTF Jay Wang
2026-10-31 13:09 ` [PATCH bpf-next 13/13] Documentation/bpf: describe CONFIG_DEBUG_INFO_BTF_LAZY Jay Wang
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=5b30c8da1e5fa12691926f41a2a845d2a6f47ce33611c249c79350e67f4e636e@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=abuehaze@amazon.com \
--cc=almagui@kernel.org \
--cc=andrii@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=doebel@amazon.de \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=jay.wang.upstream@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=memxor@gmail.com \
--cc=mhiramat@kernel.org \
--cc=mpohlack@amazon.de \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=rostedt@goodmis.org \
--cc=wanjay@amazon.com \
--cc=x86@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
all inboxes | Powered by JetHome®