lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 27 Apr 2022 13:08:34 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     menglong8.dong@...il.com
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        john fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Menglong Dong <imagedong@...cent.com>,
        Jiang Biao <benbjiang@...cent.com>,
        Hao Peng <flyingpeng@...cent.com>
Subject: Re: [PATCH bpf-next] net: bpf: support direct packet access in
 tracing program

On Wed, Apr 27, 2022 at 12:08 AM <menglong8.dong@...il.com> wrote:
>
> From: Menglong Dong <imagedong@...cent.com>
>
> For now, eBPF program of type TRACING is able to access the arguments
> of the function or raw_tracepoint directly, which makes data access
> easier and efficient. And we can also output the raw data in skb to
> user space in tracing program by bpf_skb_output() helper.
>
> However, we still can't access the packet data in 'struct sk_buff'
> directly and have to use the helper bpf_probe_read_kernel() to analyse
> packet data.
>
> Network tools, which based on eBPF TRACING, often do packet analyse
> works in tracing program for filtering, statistics, etc. For example,
> we want to trace abnormal skb free through 'kfree_skb' tracepoint with
> special ip address or tcp port.
>
> In this patch, 2 helpers are introduced: bpf_skb_get_header() and
> bpf_skb_get_end(). The pointer returned by bpf_skb_get_header() has
> the same effect with the 'data' in 'struct __sk_buff', and
> bpf_skb_get_end() has the same effect with the 'data_end'.
>
> Therefore, we can now access packet data in tracing program in this
> way:
>
>   SEC("fentry/icmp_rcv")
>   int BPF_PROG(tracing_open, struct sk_buff* skb)
>   {
>         void *data, *data_end;
>         struct ethhdr *eth;
>
>         data = bpf_skb_get_header(skb, BPF_SKB_HEADER_MAC);
>         data_end = bpf_skb_get_end(skb);
>
>         if (!data || !data_end)
>                 return 0;
>
>         if (data + sizeof(*eth) > data_end)
>                 return 0;
>
>         eth = data;
>         bpf_printk("proto:%d\n", bpf_ntohs(eth->h_proto));
>
>         return 0;
>   }
>
> With any positive reply, I'll complete the selftests programs.

See bpf_dynptr patches that Joanne is working on. That's an
alternative mechanism for data/data_end and is going to be easier and
more flexible to work with. It is the plan that once basic bpf_dynptr
functionality lands, we'll have dynptr "constructors" for xdp_buff and
sk_buff. I think it's a better path forward.

>
> Reviewed-by: Jiang Biao <benbjiang@...cent.com>
> Reviewed-by: Hao Peng <flyingpeng@...cent.com>
> Signed-off-by: Menglong Dong <imagedong@...cent.com>
> ---
>  include/linux/bpf.h      |  4 +++
>  include/uapi/linux/bpf.h | 29 ++++++++++++++++++++
>  kernel/bpf/verifier.c    |  6 +++++
>  kernel/trace/bpf_trace.c | 58 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 97 insertions(+)
>

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ