linux-kernel - Re: [RESEND PATCH bpf-next v4 1/2] bpf, sockmap: Introduce tracing capability for sockmap

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]

Message-ID: <9c311d9944fa57cec75e06cde94496d782fe4980@linux.dev>
Date: Wed, 07 May 2025 03:37:21 +0000
From: "Jiayuan Chen" <jiayuan.chen@...ux.dev>
To: "Martin KaFai Lau" <martin.lau@...ux.dev>, "Jakub Sitnicki"
 <jakub@...udflare.com>, "John Fastabend" <john.fastabend@...il.com>
Cc: "Cong Wang" <xiyou.wangcong@...il.com>, "Steven Rostedt"
 <rostedt@...dmis.org>, "Alexei Starovoitov" <ast@...nel.org>, "Daniel
 Borkmann" <daniel@...earbox.net>, "Andrii Nakryiko" <andrii@...nel.org>,
 "Eduard Zingerman" <eddyz87@...il.com>, "Song Liu" <song@...nel.org>,
 "Yonghong Song" <yonghong.song@...ux.dev>, "KP Singh"
 <kpsingh@...nel.org>, "Stanislav Fomichev" <sdf@...ichev.me>, "Hao Luo"
 <haoluo@...gle.com>, "Jiri Olsa" <jolsa@...nel.org>, "Masami Hiramatsu"
 <mhiramat@...nel.org>, "Mathieu Desnoyers"
 <mathieu.desnoyers@...icios.com>, "David S. Miller"
 <davem@...emloft.net>, "Eric Dumazet" <edumazet@...gle.com>, "Jakub
 Kicinski" <kuba@...nel.org>, "Paolo Abeni" <pabeni@...hat.com>, "Simon
 Horman" <horms@...nel.org>, "Jesper Dangaard Brouer" <hawk@...nel.org>,
 linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
 netdev@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH bpf-next v4 1/2] bpf, sockmap: Introduce tracing
 capability for sockmap

May 7, 2025 at 04:24, "Martin KaFai Lau" <martin.lau@...ux.dev> wrote:

> 
> On 5/5/25 7:51 PM, Jiayuan Chen wrote:
> 
> > 
> > Sockmap has the same high-performance forwarding capability as XDP, but
> > 
> >  operates at Layer 7.
> > 
> >  Introduce tracing capability for sockmap, to trace the execution results
> > 
> >  of BPF programs without modifying the programs themselves, similar to
> > 
> >  the existing trace_xdp_redirect{_map}.
> > 
> 
> There were advancements in bpf tracing since the trace_xdp_xxx additions.
> 
> Have you considered the fexit bpf prog and why it is not sufficient ?
> 

1.This patchset prints a large amount of information (e.g. inode ID, etc.),
some of which require kernel-internal helpers to access. These helpers are
not currently available as kfuncs, making it difficult to implement
equivalent functionality with fentry/fexit.

2. skb->_sk_redir implicitly stores both a redir action and the socket address
in a single field. Decoding this structure in fentry/fexit would require
duplicating kernel-internal logic in BPF programs. This creates maintenance
risks, as any future changes to the kernel's internal representation would
necessitate corresponding updates to the BPF programs.

3. Similar to the debate between using built-in tracepoints vs kprobes/fentry,
each approach has its tradeoffs. The key advantage of a built-in tracepoint is
seamless integration with existing tools like perf and bpftrace, which natively
support tracepoint-based tracing. For example, simply executing
'perf trace -e 'sockmap:*' ./producer' could provide sufficient visibility
without custom BPF programs.