BPF List
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Philo Lu <lulie@linux.alibaba.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, eddyz87@gmail.com, song@kernel.org,
	yonghong.song@linux.dev, john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
	jolsa@kernel.org, rostedt@goodmis.org, mhiramat@kernel.org,
	mathieu.desnoyers@efficios.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	xuanzhuo@linux.alibaba.com, dust.li@linux.alibaba.com,
	alibuda@linux.alibaba.com, guwen@linux.alibaba.com,
	hengqi@linux.alibaba.com
Subject: Re: [PATCH bpf-next] bpf: allow bpf_skb_load_bytes in tracing prog
Date: Mon, 5 Feb 2024 12:17:42 -0800	[thread overview]
Message-ID: <7da8d735-f648-439d-9a82-1bce0d81676d@linux.dev> (raw)
In-Reply-To: <20240205121038.41344-1-lulie@linux.alibaba.com>

On 2/5/24 4:10 AM, Philo Lu wrote:
> Allow using helper bpf_skb_load_bytes with BPF_PROG_TYPE_TRACING, which
> is useful for skb parsing in raw_tp/fentry/fexit, especially for
> non-linear paged skb data.
> 
> Selftests will be added if this patch is acceptable.
> 
> Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
> ---
>   kernel/trace/bpf_trace.c |  3 +++
>   net/core/filter.c        | 13 +++++++++++++
>   2 files changed, 16 insertions(+)
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 241ddf5e3895..4b928d929962 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1945,6 +1945,7 @@ static const struct bpf_func_proto bpf_perf_event_output_proto_raw_tp = {
>   extern const struct bpf_func_proto bpf_skb_output_proto;
>   extern const struct bpf_func_proto bpf_xdp_output_proto;
>   extern const struct bpf_func_proto bpf_xdp_get_buff_len_trace_proto;
> +extern const struct bpf_func_proto bpf_skb_load_bytes_trace_proto;
>   
>   BPF_CALL_3(bpf_get_stackid_raw_tp, struct bpf_raw_tracepoint_args *, args,
>   	   struct bpf_map *, map, u64, flags)
> @@ -2048,6 +2049,8 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>   		return &bpf_get_socket_ptr_cookie_proto;
>   	case BPF_FUNC_xdp_get_buff_len:
>   		return &bpf_xdp_get_buff_len_trace_proto;
> +	case BPF_FUNC_skb_load_bytes:
> +		return &bpf_skb_load_bytes_trace_proto;

It is not safe for all BPF_PROG_TYPE_TRACING hooks. e.g. fexit/__kfree_skb.

It is pretty much only safe for BPF_TRACE_RAW_TP (i.e. "tp_btf"). Take a look at 
prog_args_trusted(). Instead of making the bpf_skb_load_bytes() helper available 
to "tp_btf", I would suggest to 1) make bpf_dynptr_from_skb() kfunc available to 
"tp_btf", 2) enforce KF_TRUSTED_ARGS and 3) ensure it is rdonly (take a look at 
bpf_dynptr_from_skb_rdonly). Together with bpf_dynptr_slice() kfunc, it should 
be equivalent to the bpf_skb_load_bytes().


>   #endif
>   	case BPF_FUNC_seq_printf:
>   		return prog->expected_attach_type == BPF_TRACE_ITER ?
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 9f806cfbc654..ec5622ae8770 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -1764,6 +1764,19 @@ static const struct bpf_func_proto bpf_skb_load_bytes_proto = {
>   	.arg4_type	= ARG_CONST_SIZE,
>   };
>   
> +BTF_ID_LIST_SINGLE(bpf_skb_load_bytes_btf_ids, struct, sk_buff)
> +
> +const struct bpf_func_proto bpf_skb_load_bytes_trace_proto = {
> +	.func		= bpf_skb_load_bytes,
> +	.gpl_only	= false,
> +	.ret_type	= RET_INTEGER,
> +	.arg1_type	= ARG_PTR_TO_BTF_ID,
> +	.arg1_btf_id	= &bpf_skb_load_bytes_btf_ids[0],
> +	.arg2_type	= ARG_ANYTHING,
> +	.arg3_type	= ARG_PTR_TO_UNINIT_MEM,
> +	.arg4_type	= ARG_CONST_SIZE,
> +};
> +
>   int __bpf_skb_load_bytes(const struct sk_buff *skb, u32 offset, void *to, u32 len)
>   {
>   	return ____bpf_skb_load_bytes(skb, offset, to, len);


      reply	other threads:[~2024-02-05 20:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 12:10 [PATCH bpf-next] bpf: allow bpf_skb_load_bytes in tracing prog Philo Lu
2024-02-05 20:17 ` Martin KaFai Lau [this message]

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=7da8d735-f648-439d-9a82-1bce0d81676d@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=alibuda@linux.alibaba.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=guwen@linux.alibaba.com \
    --cc=haoluo@google.com \
    --cc=hengqi@linux.alibaba.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lulie@linux.alibaba.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sdf@google.com \
    --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