linux-kernel - Re: [PATCH bpf-next v4 0/9] bpf: tracing session supporting

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: <2393471.ElGaqSPkdT@7950hx>
Date: Sat, 20 Dec 2025 09:12:37 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Menglong Dong <menglong8.dong@...il.com>, ast@...nel.org,
 andrii@...nel.org, davem@...emloft.net, dsahern@...nel.org,
 daniel@...earbox.net, martin.lau@...ux.dev, eddyz87@...il.com,
 song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
 kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
 tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 netdev@...r.kernel.org, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v4 0/9] bpf: tracing session supporting

On 2025/12/20 00:55, Andrii Nakryiko wrote:
> On Thu, Dec 18, 2025 at 5:18 PM Menglong Dong <menglong.dong@...ux.dev> wrote:
> >
> > On 2025/12/19 08:55 Andrii Nakryiko <andrii.nakryiko@...il.com> write:
> > > On Wed, Dec 17, 2025 at 1:54 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> > > >
> > > > Hi, all.
> > > >
> > > > In this version, I combined Alexei and Andrii's advice, which makes the
> > > > architecture specific code much simpler.
> > > >
> > > > Sometimes, we need to hook both the entry and exit of a function with
> > > > TRACING. Therefore, we need define a FENTRY and a FEXIT for the target
> > > > function, which is not convenient.
> > > >
> > > > Therefore, we add a tracing session support for TRACING. Generally
> > > > speaking, it's similar to kprobe session, which can hook both the entry
> > > > and exit of a function with a single BPF program. Session cookie is also
> > > > supported with the kfunc bpf_fsession_cookie(). In order to limit the
> > > > stack usage, we limit the maximum number of cookies to 4.
> > > >
> > > > The kfunc bpf_fsession_is_return() and bpf_fsession_cookie() are both
> > > > inlined in the verifier.
> > >
> > > We have generic bpf_session_is_return() and bpf_session_cookie() (that
> > > currently works for ksession), can't you just implement them for the
> > > newly added program type instead of adding type-specific kfuncs?
> >
> > Hi, Andrii. I tried and found that it's a little hard to reuse them. The
> > bpf_session_is_return() and bpf_session_cookie() are defined as kfunc, which
> > makes we can't implement different functions for different attach type, like
> > what bpf helper does.
> 
> Are you sure? We certainly support kfunc implementation specialization
> for sleepable vs non-sleepable BPF programs. Check specialize_kfunc()
> in verifier.c

Ah, I remember it now. We do can use different kfunc version
for different case in specialize_kfunc().

> 
> >
> > The way we store "is_return" and "cookie" in fsession is different with
> > ksession. For ksession, it store the "is_return" in struct bpf_session_run_ctx.
> > Even if we move the "nr_regs" from stack to struct bpf_tramp_run_ctx,
> > it's still hard to reuse the bpf_session_is_return() or bpf_session_cookie(),
> > as the way of storing the "is_return" and "cookie" in fsession and ksession
> > is different, and it's a little difficult and complex to unify them.
> 
> I'm not saying we should unify the implementation, you have to
> implement different version of logically the same kfunc, of course.

I see. The problem now is that the prototype of bpf_session_cookie()
or bpf_session_is_return() don't satisfy our need. For bpf_session_cookie(),
we at least need the context to be the argument. However, both
of them don't have any function argument. After all, the prototype of
different version of logically the same kfunc should be the same.

I think it's not a good idea to modify the prototype of existing kfunc,
can we?

> 
> >
> > What's more, we will lose the advantage of inline bpf_fsession_is_return
> > and bpf_fsession_cookie in verifier.
> >
> 
> I'd double check that either. BPF verifier and JIT do know program
> type, so you can pick how to inline
> bpf_session_is_return()/bpf_session_cookie() based on that.

Yeah, we can inline it depend on the program type if we can solve
the prototype problem.

Thanks!
Menglong Dong


> 
> > I'll check more to see if there is a more simple way to reuse them.
> >
> > Thanks!
> > Menglong Dong
> >
> > >
[...]
> >
> >
> >
> >