[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a9a60f292e3ce862accd782bd43f8dc2491bca4.camel@gmail.com>
Date: Tue, 13 Jan 2026 13:43:51 -0800
From: Eduard Zingerman <eddyz87@...il.com>
To: Ihor Solodrai <ihor.solodrai@...ux.dev>, Alexei Starovoitov
<ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann
<daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...ux.dev>
Cc: Mykyta Yatsenko <yatsenko@...a.com>, Tejun Heo <tj@...nel.org>, Alan
Maguire <alan.maguire@...cle.com>, Benjamin Tissoires <bentiss@...nel.org>,
Jiri Kosina <jikos@...nel.org>, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
sched-ext@...ts.linux.dev
Subject: Re: [PATCH bpf-next v1 01/10] bpf: Refactor
btf_kfunc_id_set_contains
On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote:
> btf_kfunc_id_set_contains() is called by fetch_kfunc_meta() in the BPF
> verifier to get the kfunc flags stored in the .BTF_ids ELF section.
> If it returns NULL instead of a valid pointer, it's interpreted as an
> illegal kfunc usage failing the verification.
>
> There are two potential reasons for btf_kfunc_id_set_contains() to
> return NULL:
>
> 1. Provided kfunc BTF id is not present in relevant kfunc id sets.
> 2. The kfunc is not allowed, as determined by the program type
> specific filter [1].
>
> The filter functions accept a pointer to `struct bpf_prog`, so they
> might implicitly depend on earlier stages of verification, when
> bpf_prog members are set.
>
> For example, bpf_qdisc_kfunc_filter() in linux/net/sched/bpf_qdisc.c
> inspects prog->aux->st_ops [2], which is initialized in:
>
> check_attach_btf_id() -> check_struct_ops_btf_id()
>
> So far this hasn't been an issue, because fetch_kfunc_meta() is the
> only caller of btf_kfunc_id_set_contains().
>
> However in subsequent patches of this series it is necessary to
> inspect kfunc flags earlier in BPF verifier, in the add_kfunc_call().
>
> To resolve this, refactor btf_kfunc_id_set_contains() into two
> interface functions:
> * btf_kfunc_flags() that simply returns pointer to kfunc_flags
> without applying the filters
> * btf_kfunc_is_allowed() that both checks for kfunc_flags existence
> (which is a requirement for a kfunc to be allowed) and applies the
> prog filters
>
> See [3] for the previous version of this patch.
>
> [1] https://lore.kernel.org/all/20230519225157.760788-7-aditi.ghag@isovalent.com/
> [2] https://lore.kernel.org/all/20250409214606.2000194-4-ameryhung@gmail.com/
> [3] https://lore.kernel.org/bpf/20251029190113.3323406-3-ihor.solodrai@linux.dev/
>
> Signed-off-by: Ihor Solodrai <ihor.solodrai@...ux.dev>
> ---
Reviewed-by: Eduard Zingerman <eddyz87@...il.com>
> @@ -8715,6 +8730,26 @@ static int bpf_prog_type_to_kfunc_hook(enum bpf_prog_type prog_type)
> }
> }
>
> +bool btf_kfunc_is_allowed(const struct btf *btf,
> + u32 kfunc_btf_id,
> + const struct bpf_prog *prog)
> +{
Nit: I'd just add hook parameter to btf_kfunc_flags():
u32 *btf_kfunc_flags(const struct btf *btf, u32 kfunc_btf_id, const struct bpf_prog *prog,
enum btf_kfunc_hook *hook)
and allow passing NULL there, thus avoiding duplicating logic for common hook.
> + enum bpf_prog_type prog_type = resolve_prog_type(prog);
> + enum btf_kfunc_hook hook;
> + u32 *kfunc_flags;
> +
> + kfunc_flags = btf_kfunc_id_set_contains(btf, BTF_KFUNC_HOOK_COMMON, kfunc_btf_id);
> + if (kfunc_flags && __btf_kfunc_is_allowed(btf, BTF_KFUNC_HOOK_COMMON, kfunc_btf_id, prog))
> + return true;
> +
> + hook = bpf_prog_type_to_kfunc_hook(prog_type);
> + kfunc_flags = btf_kfunc_id_set_contains(btf, hook, kfunc_btf_id);
> + if (kfunc_flags && __btf_kfunc_is_allowed(btf, hook, kfunc_btf_id, prog))
> + return true;
> +
> + return false;
> +}
> +
> /* Caution:
> * Reference to the module (obtained using btf_try_get_module) corresponding to
> * the struct btf *MUST* be held when calling this function from verifier
[...]
Powered by blists - more mailing lists