netdev - Re: [PATCH bpf-next v5 00/10] bpf: fsession support

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] [day] [month] [year] [list]

Message-ID: <CADxym3Ztg28LwFsZ8K_RSmBxHuzwKcL8Q339WDoid8H95QwJGA@mail.gmail.com>
Date: Sat, 3 Jan 2026 12:41:00 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...ux.dev>, Eduard <eddyz87@...il.com>, 
	Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, jiang.biao@...ux.dev, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, X86 ML <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, bpf <bpf@...r.kernel.org>, 
	Network Development <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v5 00/10] bpf: fsession support

On Sat, Jan 3, 2026 at 7:21 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Wed, Dec 24, 2025 at 5:07 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> >
> > Hi, all.
> >
> > In this version, I did some modifications according to Andrii's
> > suggestion.
> >
> > overall
> > -------
> > 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.
> >
> > We allow the usage of bpf_get_func_ret() to get the return value in the
> > fentry of the tracing session, as it will always get "0", which is safe
> > enough and is OK.
> >
> > 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.
> >
> > kfunc design
> > ------------
> > The kfunc bpf_fsession_is_return() and bpf_fsession_cookie() are
> > introduced, and they are both inlined in the verifier.
> >
> > In current solution, we can't reuse the existing bpf_session_cookie() and
> > bpf_session_is_return(), as their prototype is different from
> > bpf_fsession_is_return() and bpf_fsession_cookie(). In
> > bpf_fsession_cookie(), we need the function argument "void *ctx" to get
> > the cookie. However, the prototype of bpf_session_cookie() is "void".
> >
> > Maybe it's possible to reuse the existing bpf_session_cookie() and
> > bpf_session_is_return(). First, we move the nr_regs from stack to struct
> > bpf_tramp_run_ctx, as Andrii suggested before. Then, we define the session
> > cookies as flexible array in bpf_tramp_run_ctx like this:
> >     struct bpf_tramp_run_ctx {
> >         struct bpf_run_ctx run_ctx;
> >         u64 bpf_cookie;
> >         struct bpf_run_ctx *saved_run_ctx;
> >         u64 func_meta; /* nr_args, cookie_index, etc */
> >         u64 fsession_cookies[];
> >     };
> >
> > The problem of this approach is that we can't inlined the bpf helper
> > anymore, such as get_func_arg, get_func_ret, get_func_arg_cnt, etc, as
> > we can't use the "current" in BPF assembly.
> >
> > So maybe it's better to use the new kfunc for now? And I'm analyzing that
> > if it is possible to inline "current" in verifier. Maybe we can convert to
> > the solution above if it success.
>
> I suspect your separate patch set to inline get_current addresses
>  this concern?

Yeah. I'm hesitating if we should do it this way. I found that
even though we can inline the "current", which can be done by
using the "call bpf_get_current_task" in verifier, it's still hard to inline
the following function:

__bpf_kfunc void *bpf_fsession_cookie(void)
{
    ......
    return run_ctx->fsession_cookies[run_ctx->func_meta >> BPF_TRAMP_M_COOKIE];
}

We can only use the r0 register during the inline, and we
need at least another one register to finish the logic above. Do we
have a temporary register that can be used here?

I'm not sure if the effort is worth it, so I think maybe it's better
to keep the current approach. As for the inline of get_current,
it's an optimization that we can do anyway.

>
> > architecture
> > ------------
> > The fsession stuff is arch related, so the -EOPNOTSUPP will be returned if
> > it is not supported yet by the arch. In this series, we only support
> > x86_64. And later, other arch will be implemented.
> >
> > Changes since v4:
>
> v5 looks to be in good shape. It needs a rebase now due to conflicts.

OK, I'll rebase and send it later.

Thanks!
Menglong Dong