BPF List
 help / color / mirror / Atom feed
From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: <sashiko-reviews@lists.linux.dev>,
	"Emil Tsalapatis" <emil@etsalapatis.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments
Date: Mon, 01 Jun 2026 01:12:32 -0400	[thread overview]
Message-ID: <DIXGEH7ZJMH5.1QKUUBCNKPVID@etsalapatis.com> (raw)
In-Reply-To: <20260530005922.90CEE1F00893@smtp.kernel.org>

On Fri May 29, 2026 at 8:59 PM EDT, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] btf_scan_type_tags incorrectly rejects valid BPF programs containing unrecognized type tags (e.g., __user, __rcu) by returning -EOPNOTSUPP.
> - [High] btf_scan_type_tags fails to discover valid type tags if they are separated from the pointer by other BTF modifiers (like CONST, VOLATILE, or TYPEDEF).
> --
>
> commit c938604636d812339744a9ba91c4659c3d79392c
> Author: Emil Tsalapatis <emil@etsalapatis.com>
>
> verifier: parse BTF type tags for function arguments
>
> This patch extracts BTF decl tag parsing into a new function and
> introduces type tag parsing for function arguments, specifically
> looking for the arena type tag on pointers.
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 17d4ab0a82068..c6a930aca67ec 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>
> [ ... ]
>
>> +static int btf_scan_type_tags(struct bpf_verifier_env *env,
>> +			      const struct btf *btf, u32 type_id,
>> +			      u32 *tags)
>> +{
>> +	const struct btf_type *t;
>> +
>> +	/* Find the first pointer type in the chain. */
>> +	t = btf_type_skip_modifiers(btf, type_id, NULL);
>> +	if (!t || !btf_type_is_ptr(t))
>> +		return 0;
>> +
>> +	/* We got a pointer, get all associated type tags. */
>> +	t = btf_type_by_id(btf, t->type);
>> +	while (t && btf_type_is_type_tag(t)) {
>
> [Severity: High]
> Does this loop terminate prematurely if the type tag is preceded by other
> modifiers like CONST, VOLATILE, or TYPEDEF?
>
> If the target type of the pointer is structured as:
> PTR -> CONST -> TYPE_TAG("arena") -> INT
>
> It appears btf_type_is_type_tag(t) would evaluate to false at the CONST
> modifier, causing the loop to exit and valid arena tags to be missed
> entirely.
>

Fair point, we can make the loop continue until it finds either a base
type or a pointer type.

>> +		const char *tag = __btf_name_by_offset(btf, t->name_off);
>> +
>> +		if (strcmp(tag, "arena") == 0) {
>> +			*tags |= ARG_TAG_ARENA;
>> +		} else {
>> +			bpf_log(&env->log, "function signature member has unsupported type tag '%s'\n",
>> +				tag);
>> +			return -EOPNOTSUPP;
>> +		}
>
> [Severity: High]
> Will this unconditionally reject valid BPF programs that contain
> unrecognized type tags like __user or __rcu?
>
> Prior to this change, standard kernel type tags on pointer arguments were
> naturally skipped by the verifier. Returning -EOPNOTSUPP here for anything
> other than arena seems like it might cause a backward compatibility
> regression for existing global subprograms that accept standard tagged
> pointers.
>

Right now imo we don't want global BPF subprogs to be able to return those
variable types in the first place. We can expand this if we ever do.

>> +
>> +		t = btf_type_by_id(btf, t->type);
>> +	}
>> +
>> +	return 0;
>> +}


  reply	other threads:[~2026-06-01  5:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30  0:22 [PATCH bpf-next v2 0/5] bpf: Minimize annotations for arena programs Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 1/5] selftests/bpf: libarena: Add "arena" BTF type tag to __arena qualifier Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments Emil Tsalapatis
2026-05-30  0:59   ` sashiko-bot
2026-06-01  5:12     ` Emil Tsalapatis [this message]
2026-06-01 18:37   ` Eduard Zingerman
2026-06-01 19:13     ` Emil Tsalapatis
2026-06-01 19:14       ` Eduard Zingerman
2026-05-30  0:22 ` [PATCH bpf-next v2 3/5] bpf: Allow subprogs to return arena pointers Emil Tsalapatis
2026-05-30  4:54   ` sashiko-bot
2026-06-01  5:09     ` Emil Tsalapatis
2026-06-01 19:01   ` Eduard Zingerman
2026-06-02  0:06     ` Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 4/5] selftests/bpf: Remove __arg_arena from the codebase Emil Tsalapatis
2026-05-30  5:03   ` sashiko-bot
2026-05-31  5:18     ` Alexei Starovoitov
2026-06-01  5:03       ` Emil Tsalapatis
2026-06-01 19:06   ` Eduard Zingerman
2026-05-30  0:22 ` [PATCH bpf-next v2 5/5] selftests/bpf: libarena: Directly return arena pointers from functions Emil Tsalapatis
2026-06-01 19:07   ` Eduard Zingerman

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=DIXGEH7ZJMH5.1QKUUBCNKPVID@etsalapatis.com \
    --to=emil@etsalapatis.com \
    --cc=bpf@vger.kernel.org \
    --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