public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Martin Teichmann <martin.teichmann@xfel.eu>, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org
Subject: Re: [PATCH v2 bpf] bpf: properly verify tail call behavior
Date: Tue, 04 Nov 2025 14:30:05 -0800	[thread overview]
Message-ID: <3fd72f5e97f7c5e863d3686d5eb062048e9192b2.camel@gmail.com> (raw)
In-Reply-To: <20251104133004.2559222-1-martin.teichmann@xfel.eu>

On Tue, 2025-11-04 at 14:30 +0100, Martin Teichmann wrote:
> A successful ebpf tail call does not return to the caller, but to the
> caller-of-the-caller, often just finishing the ebpf program altogether.
> 
> Any restrictions that the verifier needs to take into account - notably
> the fact that the tail call might have modified packet pointers - are to
> be checked on the caller-of-the-caller. Checking it on the caller made
> the verifier refuse perfectly fine programs that would use the packet
> pointers after a tail call, which is no problem as this code is only
> executed if the tail call was unsuccessful, i.e. nothing happened.
> 
> This patch simulates the behavior of a tail call in the verifier. A
> conditional jump to the code after the tail call is added for the case
> of an unsucessful tail call, and a return to the caller is simulated for
> a successful tail call.
> 
> For the successful case we assume that the tail call returns an int,
> as tail calls are currently only allowed in functions that return and
> int. We always assume that the tail call modified the packet pointers,
> as we do not know what the tail call did.
> 
> For the unsuccessful case we know nothing happened, so we do not need to
> add new constraints. Some test are added, notably one corner case found
> by Eduard Zingerman.
> 
> Fixes: 1a4607ffba35 ("bpf: consider that tail calls invalidate packet pointers")
> Link: https://lore.kernel.org/bpf/20251029105828.1488347-1-martin.teichmann@xfel.eu/
> Signed-off-by: Martin Teichmann <martin.teichmann@xfel.eu>
> ---

Hi Martin,

I think this is a viable idea.
Please see a few notes below.

>  kernel/bpf/verifier.c                         | 25 ++++++++++--
>  .../selftests/bpf/progs/verifier_sock.c       | 39 ++++++++++++++++++-
>  2 files changed, 59 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index e4928846e763..9a091e0f2f07 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -11005,6 +11005,10 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
>  	bool in_callback_fn;
>  	int err;
>  
> +	err = bpf_update_live_stack(env);
> +	if (err)
> +		return err;
> +
>  	callee = state->frame[state->curframe];
>  	r0 = &callee->regs[BPF_REG_0];
>  	if (r0->type == PTR_TO_STACK) {
> @@ -11911,6 +11915,24 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>  		env->prog->call_get_func_ip = true;
>  	}
>  
> +	if (func_id == BPF_FUNC_tail_call) {
> +		if (env->cur_state->curframe) {
> +			struct bpf_verifier_state *branch;
> +			mark_reg_scratched(env, BPF_REG_0);
> +			branch = push_stack(env, env->insn_idx + 1, env->insn_idx, false);
> +			if (IS_ERR(branch))
> +				return PTR_ERR(branch);
> +			clear_all_pkt_pointers(env);
> +			mark_reg_unknown(env, regs, BPF_REG_0);
> +			err = prepare_func_exit(env, &env->insn_idx);
> +			if (err)
> +				return err;
> +			env->insn_idx--;
> +		} else {
> +			changes_data = false;
> +		}
> +	}
> +

Could you please update bpf_insn_successors()?
Technically, it should do something similar to what Anton does in [1].
W/o bpf_insn_successors() reflecting that control flow might jump over
the instructions between tail call and function exit, verifier might
assume that some writes to parent stack always happen, which is not
the case.

I think this is a long standing bug, was here even before my changes
for stack liveness.

[1] https://lore.kernel.org/bpf/20251102205722.3266908-7-a.s.protopopov@gmail.com/

>  	if (changes_data)
>  		clear_all_pkt_pointers(env);
>  	return 0;
> @@ -19876,9 +19898,6 @@ static int process_bpf_exit_full(struct bpf_verifier_env *env,
>  		return PROCESS_BPF_EXIT;
>  
>  	if (env->cur_state->curframe) {
> -		err = bpf_update_live_stack(env);
> -		if (err)
> -			return err;
>  		/* exit from nested function */
>  		err = prepare_func_exit(env, &env->insn_idx);
>  		if (err)
> diff --git a/tools/testing/selftests/bpf/progs/verifier_sock.c b/tools/testing/selftests/bpf/progs/verifier_sock.c
> index 2b4610b53382..a2132c72d3b8 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_sock.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_sock.c
> @@ -1117,10 +1117,17 @@ int tail_call(struct __sk_buff *sk)
>  	return 0;
>  }
>  
> -/* Tail calls invalidate packet pointers. */
> +static __noinline
> +int static_tail_call(struct __sk_buff *sk)
> +{
> +	bpf_tail_call_static(sk, &jmp_table, 0);
> +	return 0;
> +}
> +
> +/* Tail calls in sub-programs invalidate packet pointers. */
>  SEC("tc")
>  __failure __msg("invalid mem access")
> -int invalidate_pkt_pointers_by_tail_call(struct __sk_buff *sk)
> +int invalidate_pkt_pointers_by_global_tail_call(struct __sk_buff *sk)
>  {
>  	int *p = (void *)(long)sk->data;
>  
> @@ -1131,4 +1138,32 @@ int invalidate_pkt_pointers_by_tail_call(struct __sk_buff *sk)
>  	return TCX_PASS;
>  }
>

Usually, test cases are added as separate commits.
Changes to tests are bundled with changes to kernel only if that is
necessary to keep bisect happy (tests passing on each commit).

--

Also, could you please add a test case verifying that:
- Precision propagation works correctly when processing program
  fragment containing tail call. (I think that is_jmp_point() logic
  should kick-in automatically here, but would be nice to have a
  test).
- Live stack tracking works correctly under the same circumstances.
  (Test case exercising bpf_update_live_stack() call you inserted).

See verifier_subprog_precision.c and verifier_live_stack.c for
examples.

> +/* Tail calls in static sub-programs invalidate packet pointers. */
> +SEC("tc")
> +__failure __msg("invalid mem access")
> +int invalidate_pkt_pointers_by_static_tail_call(struct __sk_buff *sk)
> +{
> +	int *p = (void *)(long)sk->data;
> +
> +	if ((void *)(p + 1) > (void *)(long)sk->data_end)
> +		return TCX_DROP;
> +	static_tail_call(sk);
> +	*p = 42; /* this is unsafe */
> +	return TCX_PASS;
> +}
> +
> +/* Direct tail calls do not invalidate packet pointers. */
> +SEC("tc")
> +__success
> +int invalidate_pkt_pointers_by_tail_call(struct __sk_buff *sk)
> +{
> +	int *p = (void *)(long)sk->data;
> +
> +	if ((void *)(p + 1) > (void *)(long)sk->data_end)
> +		return TCX_DROP;
> +	bpf_tail_call_static(sk, &jmp_table, 0);
> +	*p = 42; /* this is NOT unsafe: tail calls don't return */
> +	return TCX_PASS;
> +}
> +
>  char _license[] SEC("license") = "GPL";

  parent reply	other threads:[~2025-11-04 22:30 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 10:58 [PATCH bpf] bpf: tail calls do not modify packet data Martin Teichmann
2025-10-31 19:24 ` Eduard Zingerman
2025-11-03  8:56   ` Teichmann, Martin
2025-11-03 17:34     ` Eduard Zingerman
2025-11-04 12:54       ` Teichmann, Martin
2025-11-04 13:30   ` [PATCH v2 bpf] bpf: properly verify tail call behavior Martin Teichmann
2025-11-04 13:58     ` bot+bpf-ci
2025-11-04 18:05       ` Alexei Starovoitov
2025-11-04 22:30     ` Eduard Zingerman [this message]
2025-11-05 17:40   ` [PATCH v3 bpf-next 0/2] " Martin Teichmann
2025-11-05 19:08     ` Eduard Zingerman
2025-11-06 10:52       ` [PATCH v4 " Martin Teichmann
2025-11-06 10:52       ` [PATCH v4 bpf-next 1/2] " Martin Teichmann
2025-11-06 10:52       ` [PATCH v4 bpf-next 2/2] bpf: test the proper verification of tail calls Martin Teichmann
2025-11-06 19:50         ` Eduard Zingerman
2025-11-10 15:18           ` [PATCH v4 bpf-next 0/2] bpf: properly verify tail call behavior Martin Teichmann
2025-11-10 15:18           ` [PATCH v4 bpf-next 1/2] " Martin Teichmann
2025-11-10 20:28             ` Eduard Zingerman
2025-11-10 23:39               ` Eduard Zingerman
2025-11-13 11:46               ` Teichmann, Martin
2025-11-13 16:09                 ` Alexei Starovoitov
2025-11-18 13:39               ` [PATCH v5 bpf-next 0/4] " Martin Teichmann
2025-11-18 13:39               ` [PATCH v5 bpf-next 1/4] " Martin Teichmann
2025-11-18 19:34                 ` Eduard Zingerman
2025-11-19 16:03                   ` [PATCH v6 bpf-next 0/4] " Martin Teichmann
2025-11-19 16:03                   ` [PATCH v6 bpf-next 1/4] " Martin Teichmann
2025-11-22  2:00                     ` patchwork-bot+netdevbpf
2025-11-19 16:03                   ` [PATCH v6 bpf-next 2/4] bpf: test the proper verification of tail calls Martin Teichmann
2025-11-19 16:03                   ` [PATCH v6 bpf-next 3/4] bpf: correct stack liveness for " Martin Teichmann
2025-11-19 16:33                     ` bot+bpf-ci
2025-12-12  2:06                     ` Chris Mason
2025-11-19 16:03                   ` [PATCH v6 bpf-next 4/4] bpf: test the correct stack liveness of " Martin Teichmann
2025-11-18 13:39               ` [PATCH v5 bpf-next 2/4] bpf: test the proper verification " Martin Teichmann
2025-11-18 22:47                 ` Eduard Zingerman
2025-11-18 13:39               ` [PATCH v5 bpf-next 3/4] bpf: correct stack liveness for " Martin Teichmann
2025-11-18 22:54                 ` Eduard Zingerman
2025-11-18 13:39               ` [PATCH v5 bpf-next 4/4] bpf: test the correct stack liveness of " Martin Teichmann
2025-11-18 22:55                 ` Eduard Zingerman
2025-11-19  0:13                   ` Alexei Starovoitov
2025-11-10 15:18           ` [PATCH v4 bpf-next 2/2] bpf: test the proper verification " Martin Teichmann
2025-11-10 20:32             ` Eduard Zingerman
2025-11-05 17:40   ` [PATCH v3 bpf-next 1/2] bpf: properly verify tail call behavior Martin Teichmann
2025-11-05 17:40   ` [PATCH v3 bpf-next 2/2] bpf: test the proper verification of tail calls Martin Teichmann

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=3fd72f5e97f7c5e863d3686d5eb062048e9192b2.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=martin.teichmann@xfel.eu \
    /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