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 v5 bpf-next 1/4] bpf: properly verify tail call behavior
Date: Tue, 18 Nov 2025 11:34:51 -0800 [thread overview]
Message-ID: <622f4e7645e426ae180e4511877eb90ceb1b1063.camel@gmail.com> (raw)
In-Reply-To: <20251118133944.979865-2-martin.teichmann@xfel.eu>
On Tue, 2025-11-18 at 14:39 +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.
>
> This approach also allows to check other problems that may occur with
> tail calls, namely we are now able to check that precision is properly
> propagated into subprograms using tail calls, as well as checking the
> live slots in such a subprogram.
>
> 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>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
[...]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 098dd7f21c89..117a2b1cf87c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[...]
> @@ -11970,6 +11979,25 @@ 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--;
This insn_idx adjustment is a bit unfortunate, but refactoring getting
rid of it is probably out of scope for this series.
next prev parent reply other threads:[~2025-11-18 19:34 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
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 [this message]
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=622f4e7645e426ae180e4511877eb90ceb1b1063.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