From: Martin KaFai Lau <martin.lau@linux.dev>
To: Philo Lu <lulie@linux.alibaba.com>
Cc: daniel@iogearbox.net, john.fastabend@gmail.com, ast@kernel.org,
andrii@kernel.org, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
mykolal@fb.com, shuah@kernel.org, drosen@google.com,
xuanzhuo@linux.alibaba.com, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Allow bpf_dynptr_from_skb() for tp_btf
Date: Mon, 6 May 2024 14:39:36 -0700 [thread overview]
Message-ID: <5d4f681a-6636-4c98-9b1e-5c5170b79f7c@linux.dev> (raw)
In-Reply-To: <20240430121805.104618-2-lulie@linux.alibaba.com>
On 4/30/24 5:18 AM, Philo Lu wrote:
> Making tp_btf able to use bpf_dynptr_from_skb(), which is useful for skb
> parsing, especially for non-linear paged skb data. This is achieved by
> adding KF_TRUSTED_ARGS flag to bpf_dynptr_from_skb and registering it
> for TRACING progs. With KF_TRUSTED_ARGS, args from fentry/fexit are
> excluded, so that unsafe progs like fexit/__kfree_skb are not allowed.
>
> We also need the skb dynptr to be read-only in tp_btf. Because
> may_access_direct_pkt_data() returns false by default when checking
> bpf_dynptr_from_skb, there is no need to add BPF_PROG_TYPE_TRACING to it
> explicitly.
>
> Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
> ---
> net/core/filter.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 786d792ac816..399492970b8c 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -11990,7 +11990,7 @@ int bpf_dynptr_from_skb_rdonly(struct sk_buff *skb, u64 flags,
> }
>
> BTF_KFUNCS_START(bpf_kfunc_check_set_skb)
> -BTF_ID_FLAGS(func, bpf_dynptr_from_skb)
> +BTF_ID_FLAGS(func, bpf_dynptr_from_skb, KF_TRUSTED_ARGS)
I can see the usefulness of having the same way parsing the header as the
tc-bpf. However, it implicitly means the skb->data and skb_shinfo are trusted
also. afaik, it should be as long as skb is not NULL.
From looking at include/trace/events, there is case that skb is NULL. e.g.
tcp_send_reset. It is not something new though, e.g. using skb->sk in the tp_btf
could be bad already. This should be addressed before allowing more kfunc/helper.
I would like to hear how others think about it.
pw-bot: cr
> BTF_KFUNCS_END(bpf_kfunc_check_set_skb)
>
> BTF_KFUNCS_START(bpf_kfunc_check_set_xdp)
> @@ -12039,6 +12039,7 @@ static int __init bpf_kfunc_init(void)
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_LWT_XMIT, &bpf_kfunc_set_skb);
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_LWT_SEG6LOCAL, &bpf_kfunc_set_skb);
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_NETFILTER, &bpf_kfunc_set_skb);
> + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_kfunc_set_skb);
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_XDP, &bpf_kfunc_set_xdp);
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
> &bpf_kfunc_set_sock_addr);
next prev parent reply other threads:[~2024-05-06 21:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 12:18 [PATCH bpf-next 0/2] bpf: Allow skb dynptr for tp_btf Philo Lu
2024-04-30 12:18 ` [PATCH bpf-next 1/2] bpf: Allow bpf_dynptr_from_skb() " Philo Lu
2024-05-06 21:39 ` Martin KaFai Lau [this message]
2024-05-06 23:29 ` Alexei Starovoitov
2024-05-09 0:24 ` Martin KaFai Lau
2024-05-09 1:11 ` Philo Lu
2024-04-30 12:18 ` [PATCH bpf-next 2/2] selftests/bpf: Expand skb dynptr selftests " Philo Lu
2024-05-06 21:43 ` Martin KaFai Lau
2024-05-07 3:15 ` Philo Lu
2024-05-09 0:22 ` Martin KaFai Lau
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=5d4f681a-6636-4c98-9b1e-5c5170b79f7c@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=drosen@google.com \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=lulie@linux.alibaba.com \
--cc=mykolal@fb.com \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=xuanzhuo@linux.alibaba.com \
--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