linux-kernel - Re: [PATCH bpf-next v7 07/11] bpf,x86: add fsession support for x86

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: <3026409.e9J7NaK4W3@7940hx>
Date: Wed, 07 Jan 2026 15:55:52 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: menglong8.dong@...il.com, ast@...nel.org, andrii@...nel.org,
 bot+bpf-ci@...nel.org
Cc: 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,
 ast@...nel.org, andrii@...nel.org, daniel@...earbox.net,
 martin.lau@...nel.org, eddyz87@...il.com, yonghong.song@...ux.dev,
 clm@...a.com, ihor.solodrai@...ux.dev
Subject:
 Re: [PATCH bpf-next v7 07/11] bpf,x86: add fsession support for x86_64

On 2026/1/7 15:11 bot+bpf-ci@...nel.org write:
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index a87304161d45..32c13175bc65 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -3094,12 +3094,17 @@ static int emit_cond_near_jump(u8 **pprog, void *func, void *ip, u8 jmp_cond)
> >  static int invoke_bpf(const struct btf_func_model *m, u8 **pprog,
> >  		      struct bpf_tramp_links *tl, int stack_size,
> >  		      int run_ctx_off, bool save_ret,
> > -		      void *image, void *rw_image)
> > +		      void *image, void *rw_image, u64 func_meta)
> >  {
> >  	int i;
> >  	u8 *prog = *pprog;
> >
> >  	for (i = 0; i < tl->nr_links; i++) {
> > +		if (tl->links[i]->link.prog->call_session_cookie) {
> > +			/* 'stack_size + 8' is the offset of func_md in stack */
> > +			emit_st_r0_imm64(&prog, func_meta, stack_size + 8);
> > +			func_meta -= (1 << BPF_TRAMP_M_COOKIE);
> > +		}
> 
> This decrement of func_meta is problematic for fsession programs. When
> invoke_bpf() is called for fentry, func_meta gets decremented for each
> program with call_session_cookie. Later, when invoke_bpf() is called
> for fexit, it receives this already-decremented func_meta value.
> 
> Since fsession programs appear in both fentry and fexit lists (same
> program object), call_session_cookie is true for both. The fexit part
> will see a different cookie offset than the fentry part saw.
> 
> For example, with one fsession program:
>   - fentry stores func_meta with cookie offset N, then decrements to N-1
>   - fexit receives N-1, stores it, and the BPF program reads offset N-1
> 
> Should the func_meta offset be reset for fexit so that each fsession
> program's fentry and fexit parts access the same cookie slot?
> 
> [ ... ]
> 
> > @@ -3383,9 +3395,19 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
> >  		}
> >  	}
> >
> > +	if (bpf_fsession_cnt(tlinks)) {
> > +		/* clear all the session cookies' value */
> > +		for (int i = 0; i < cookie_cnt; i++)
> > +			emit_st_r0_imm64(&prog, 0, cookie_off - 8 * i);
> > +		/* clear the return value to make sure fentry always get 0 */
> > +		emit_st_r0_imm64(&prog, 0, 8);
> > +	}
> > +	func_meta = nr_regs + (((cookie_off - regs_off) / 8) << BPF_TRAMP_M_COOKIE);
> > +
> >  	if (fentry->nr_links) {
> >  		if (invoke_bpf(m, &prog, fentry, regs_off, run_ctx_off,
> > -			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image))
> > +			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image,
> > +			       func_meta))
> >  			return -EINVAL;
> >  	}
> 
> [ ... ]
> 
> > @@ -3445,9 +3467,14 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
> >  		}
> >  	}
> >
> > +	/* set the "is_return" flag for fsession */
> > +	func_meta += (1 << BPF_TRAMP_M_IS_RETURN);
> > +	if (bpf_fsession_cnt(tlinks))
> > +		emit_st_r0_imm64(&prog, func_meta, nregs_off);
> > +
> >  	if (fexit->nr_links) {
> >  		if (invoke_bpf(m, &prog, fexit, regs_off, run_ctx_off,
> > -			       false, image, rw_image)) {
> > +			       false, image, rw_image, func_meta)) {
> 
> At this point func_meta has already been decremented during the fentry
> invoke_bpf() call above. When invoke_bpf() processes the fexit list and
> encounters an fsession program (which has call_session_cookie set since
> it is the same program object), it will store this modified func_meta.

I think you misunderstand something. The "func_meta" that modified in
invoke_bpf() will not affect the value of "func_meta" here. We pass the value
of func_meta to invoke_bpf(), not the address.

This part should be OK, as it is covered by the selftests.

Thanks!
Menglong Dong

> 
> The cookie offset encoded in func_meta will be different from what the
> fentry part stored, causing bpf_session_cookie() to return a pointer to
> a different memory location for fexit than for fentry.
> 
> > +			ret = -EINVAL;
> > +			goto cleanup;
> > +		}
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/20773233136
>