From: Slava Imameev <slava.imameev@crowdstrike.com>
To: <eddyz87@gmail.com>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <bpf@vger.kernel.org>,
<daniel@iogearbox.net>, <davem@davemloft.net>,
<edumazet@google.com>, <haoluo@google.com>, <horms@kernel.org>,
<john.fastabend@gmail.com>, <jolsa@kernel.org>,
<kpsingh@kernel.org>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<linux-open-source@crowdstrike.com>, <martin.lau@linux.dev>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>, <sdf@fomichev.me>,
<shuah@kernel.org>, <slava.imameev@crowdstrike.com>,
<song@kernel.org>, <yonghong.song@linux.dev>
Subject: Re: [PATCH bpf-next v4 1/2] bpf: Support new pointer param types via SCALAR_VALUE for trampolines
Date: Thu, 12 Mar 2026 00:07:11 +1100 [thread overview]
Message-ID: <20260311130711.33966-1-slava.imameev@crowdstrike.com> (raw)
In-Reply-To: <979c7539ac475b3c428f609066e947844b6dd8b0.camel@gmail.com>
Tue, 10 Mar 2026 11:52:10 -0700, Eduard Zingerman wrote:
> [...]
>
> > I verified whether PTR->FUNC, PTR->DATASEC, PTR->VAR can be passed to
> > btf_ctx_access() in the current mainline.
> >
> > I added helpers that inject PTR->FUNC, PTR->DATASEC, PTR->VAR as pre or
> > post calls to btf_check_meta(). In all cases, the BPF program load
> > failed with errors "arg0 type FUNC / DATASEC / VAR is not a struct",
> > which indicates that btf_check_meta() can indeed be called with
> > PTR->FUNC, PTR->DATASEC, PTR->VAR.
> >
> > If the condition for pointer check is changed to
> > `if (!btf_type_is_struct_ptr(btf, t))`, these BPF programs will load
> > successfully with arguments set to scalar().
> >
> > Do we accept this change in behavior?
>
> Kernel validates BTF before loading, see kernel/bpf/btf.c:btf_resolve().
> Validation is applied to kernel, module and program-level BTF.
> Does BTF containing PTR->DATASEC and PTR->VAR pass validation?
> If it does, validation should be updated to reject such cases.
> For PTR->FUNC, which one is legit PTR->FUNC or PTR->FUNC_PROTO?
> The legit one should be allowed and invalid should be rejected
> at validation phase.
>
> You can craft invalid BTF as in the following selftest:
> tools/testing/selftests/bpf/prog_tests/btf.c.
>
> [...]
Invalid BTF pointer types PTR->DATASEC, PTR->FUNC, PTR->VAR are
rejected by btf_ptr_resolve(), which is called through the sequence
btf_check_all_types()->btf_resolve()->btf_ptr_resolve().
PTR->FUNC_PROTO is a valid type.
vmlinux BTF is processed by btf_parse_vmlinux, which calls
btf_parse_base. Since btf_parse_base doesn't call btf_check_all_types,
it becomes possible to invoke btf_ctx_access with PTR->DATASEC,
PTR->FUNC, PTR->VAR in case of vmlinux BTF.
Modules and programs BTF are processed by btf_parse, which calls
btf_check_all_types and detects invalid pointer types, so
btf_ctx_access cannot see PTR->DATASEC, PTR->FUNC, PTR->VAR in
these cases.
If btf_check_all_types is added to btf_parse_base, invalid pointer
types get detected inside btf_parse_vmlinux, resulting in failure
to process vmlinux BTF and effectively disabling BPF. libbpf
returns this error:
libbpf: Error in bpf_object__probe_loading(): -EINVAL. Couldn't load
trivial BPF program. Make sure your kernel supports BPF
(CONFIG_BPF_SYSCALL=y) and/or that RLIMIT_MEMLOCK is set to big
enough value.
If vmlinux BTF is trusted not to contain invalid types like
PTR->DATASEC, PTR->FUNC, PTR->VAR, which seems reasonable, we can
conclude that btf_ctx_access will never observe these types.
Adopting the view that vmlinux BTF is consistent, we can replace
btf_ctx_access's condition for inferring scalar() for pointers
from "if (is_void_or_int_ptr(btf, t))" to
"if (!btf_type_is_struct_ptr(btf, t))".
Otherwise, we need to either check types for vmlinux BTF,
incurring additional cost, or use explicit checks for pointer types
that can be inferred as scalar by btf_ctx_access to exclude invalid
types. This would let invalid pointer types be rejected with an
error like "func 'bpf_fentry_test_invalid_ptr_func' arg0 type FUNC
is not a struct".
next prev parent reply other threads:[~2026-03-11 13:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 9:54 [PATCH bpf-next v4 0/2] bpf: Add multi-level pointer parameter support for trampolines Slava Imameev
2026-03-03 9:54 ` [PATCH bpf-next v4 1/2] bpf: Support new pointer param types via SCALAR_VALUE " Slava Imameev
2026-03-03 20:05 ` Eduard Zingerman
2026-03-03 21:49 ` Slava Imameev
2026-03-03 22:43 ` Eduard Zingerman
2026-03-04 0:22 ` Slava Imameev
2026-03-04 0:36 ` Alexei Starovoitov
2026-03-04 0:38 ` Eduard Zingerman
2026-03-10 12:16 ` Slava Imameev
2026-03-10 18:52 ` Eduard Zingerman
2026-03-11 13:07 ` Slava Imameev [this message]
2026-03-11 16:31 ` Eduard Zingerman
2026-03-03 9:54 ` [PATCH bpf-next v4 2/2] selftests/bpf: Add trampolines single and multi-level pointer params test coverage Slava Imameev
2026-03-03 20:08 ` Eduard Zingerman
2026-03-03 22:14 ` Slava Imameev
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=20260311130711.33966-1-slava.imameev@crowdstrike.com \
--to=slava.imameev@crowdstrike.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-open-source@crowdstrike.com \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.