linux-kernel - Re: [PATCH bpf-next v9 05/11] bpf: support fsession for bpf_session

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1917811.atdPhlSkOF@7940hx>
Date: Wed, 14 Jan 2026 10:48:48 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Menglong Dong <menglong8.dong@...il.com>,
 Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: ast@...nel.org, andrii@...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, davem@...emloft.net,
 dsahern@...nel.org, tglx@...utronix.de, mingo@...hat.com,
 jiang.biao@...ux.dev, bp@...en8.de, dave.hansen@...ux.intel.com,
 x86@...nel.org, hpa@...or.com, bpf@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH bpf-next v9 05/11] bpf: support fsession for bpf_session_cookie

On 2026/1/14 09:22 Andrii Nakryiko <andrii.nakryiko@...il.com> write:
> On Sat, Jan 10, 2026 at 6:12 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> >
> > Implement session cookie for fsession. In order to limit the stack usage,
> > we make 4 as the maximum of the cookie count.
> 
> This 4 is so random, tbh. Do we need to artificially limit it? Even if
> all BPF_MAX_TRAMP_LINKS = 38 where using session cookies, it would be
> 304 bytes. Not insignificant, but also not world-ending and IMO so
> unlikely that I wouldn't add extra limits at all.

I'll remove the limitation in the next version.

> 
> >
> > The offset of the current cookie is stored in the
> > "(ctx[-1] >> BPF_TRAMP_M_COOKIE) & 0xFF". Therefore, we can get the
> > session cookie with ctx[-offset].
> 
> 
> ctx here is assumed u64 *, right? So offset is in 8-byte units? Can
> you clarify please?

Yes, ctx is u64 * and the offset is 8-byte units. I'll describe it
here.

> 
> >
> > The stack will look like this:
> >
> >   return value  -> 8 bytes
> >   argN          -> 8 bytes
> >   ...
[...]
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 2640ec2157e1..a416050e0dd2 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1231,6 +1231,7 @@ enum {
> >
> >  #define BPF_TRAMP_M_NR_ARGS    0
> >  #define BPF_TRAMP_M_IS_RETURN  8
> > +#define BPF_TRAMP_M_COOKIE     9
> 
> this is not wrong, but certainly weird. Why not make IS_RETURN to be
> the upper bit (63) and keep cookie as a proper second byte?

OK, I think it make sense, which can make the usage of the
func_meta more clear. So for the flag bit, we put it at the
high significant bit. And for the offset filed, we put it at the
low significant bit.

> 
> 
> (also I think all these should drop _M and have _SHIFT suffix)
> 

Glad to hear some advice about the name. I'll use it.

> 
> >