mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®