From: Nick Zavaritsky <mejedi@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, martin.lau@linux.dev, kernel-team@fb.com,
yonghong.song@linux.dev
Subject: Re: [PATCH bpf v2 7/8] bpf: consider that tail calls invalidate packet pointers
Date: Tue, 10 Dec 2024 11:35:35 +0100 [thread overview]
Message-ID: <EC7AA65F-13D1-4CA2-A575-44DA02332A4E@gmail.com> (raw)
In-Reply-To: <20241210041100.1898468-8-eddyz87@gmail.com>
> Tail-called programs could execute any of the helpers that invalidate
> packet pointers. Hence, conservatively assume that each tail call
> invalidates packet pointers.
Tail calls look like a clear limitation of "auto-infer packet
invalidation effect" approach. Correct solution requires propagating
effects in the dynamic callee-caller graph, unlikely to ever happen.
I'm curious if assuming that every call to a global sub program
invalidates packet pointers might be an option. Does it break too many
programs in the wild?
From an end-user perspective, the presented solution makes debugging
verifier errors harder. An error message doesn't tell which call
invalidated pointers. Whether verifier considers a particular sub
program as pointer-invalidating is not revealed. I foresee exciting
debugging sessions.
It probably doesn't matter, but I don't like bpf_xdp_adjust_meta(xdp, 0)
hack to mark a program as pointer-invalidating either.
I would've preferred a simple static rule "calls to global sub programs
invalidate packet pointers" with an optional decl tag to mark a sub
program as non-invalidating, in line with "arg:nonnull".
> Making the change in bpf_helper_changes_pkt_data() automatically makes
> use of check_cfg() logic that computes 'changes_pkt_data' effect for
> global sub-programs, such that the following program could be
> rejected:
>
> int tail_call(struct __sk_buff *sk)
> {
> bpf_tail_call_static(sk, &jmp_table, 0);
> return 0;
> }
>
> SEC("tc")
> int not_safe(struct __sk_buff *sk)
> {
> int *p = (void *)(long)sk->data;
> ... make p valid ...
> tail_call(sk);
> *p = 42; /* this is unsafe */
> ...
> }
>
> The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that
> can invalidate packet pointers. Otherwise, it can't be freplaced with
> tailcall_freplace.c:entry_freplace() that does a tail call.
>
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> ---
> net/core/filter.c | 2 ++
> tools/testing/selftests/bpf/progs/tc_bpf2bpf.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index efb75eed2e35..21131ec25f24 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -7924,6 +7924,8 @@ bool bpf_helper_changes_pkt_data(enum bpf_func_id func_id)
> case BPF_FUNC_xdp_adjust_head:
> case BPF_FUNC_xdp_adjust_meta:
> case BPF_FUNC_xdp_adjust_tail:
> + /* tail-called program could call any of the above */
> + case BPF_FUNC_tail_call:
> return true;
> default:
> return false;
> diff --git a/tools/testing/selftests/bpf/progs/tc_bpf2bpf.c b/tools/testing/selftests/bpf/progs/tc_bpf2bpf.c
> index d1a57f7d09bd..fe6249d99b31 100644
> --- a/tools/testing/selftests/bpf/progs/tc_bpf2bpf.c
> +++ b/tools/testing/selftests/bpf/progs/tc_bpf2bpf.c
> @@ -11,6 +11,8 @@ int subprog_tc(struct __sk_buff *skb)
>
> __sink(skb);
> __sink(ret);
> + /* let verifier know that 'subprog_tc' can change pointers to skb->data */
> + bpf_skb_change_proto(skb, 0, 0);
> return ret;
> }
>
> --
> 2.47.0
>
next prev parent reply other threads:[~2024-12-10 10:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 4:10 [PATCH bpf v2 0/8] bpf: track changes_pkt_data property for global functions Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 1/8] bpf: add find_containing_subprog() utility function Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 2/8] bpf: refactor bpf_helper_changes_pkt_data to use helper number Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 3/8] bpf: track changes_pkt_data property for global functions Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 4/8] selftests/bpf: test for changing packet data from " Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 5/8] bpf: check changes_pkt_data property for extension programs Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 6/8] selftests/bpf: freplace tests for tracking of changes_packet_data Eduard Zingerman
2024-12-10 4:10 ` [PATCH bpf v2 7/8] bpf: consider that tail calls invalidate packet pointers Eduard Zingerman
2024-12-10 10:35 ` Nick Zavaritsky [this message]
2024-12-10 18:23 ` Alexei Starovoitov
2024-12-10 18:29 ` Eduard Zingerman
2024-12-10 18:31 ` Alexei Starovoitov
2024-12-10 18:52 ` Eduard Zingerman
2024-12-10 19:00 ` Alexei Starovoitov
2024-12-10 19:06 ` Eduard Zingerman
2024-12-10 4:11 ` [PATCH bpf v2 8/8] selftests/bpf: validate that tail call invalidates " Eduard Zingerman
2024-12-10 18:40 ` [PATCH bpf v2 0/8] bpf: track changes_pkt_data property for global functions patchwork-bot+netdevbpf
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=EC7AA65F-13D1-4CA2-A575-44DA02332A4E@gmail.com \
--to=mejedi@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox