netdev - Re: [PATCH bpf-next 1/4] bpf, verifier: Support direct helper calls from prologue/epilogue

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: <f9ffbb877c73e5655fa6cfc4480624a320fcf94e.camel@gmail.com>
Date: Mon, 19 Jan 2026 14:44:19 -0800
From: Eduard Zingerman <eddyz87@...il.com>
To: Jakub Sitnicki <jakub@...udflare.com>, bpf@...r.kernel.org
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>,  John Fastabend <john.fastabend@...il.com>, Andrii
 Nakryiko <andrii@...nel.org>, Martin KaFai Lau	 <martin.lau@...ux.dev>,
 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>,  Amery Hung
 <ameryhung@...il.com>, netdev@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [PATCH bpf-next 1/4] bpf, verifier: Support direct helper calls
 from prologue/epilogue

On Mon, 2026-01-19 at 20:53 +0100, Jakub Sitnicki wrote:
> Prepare to remove support for calling kfuncs from prologue & epilogue.
> 
> Instead allow direct helpers calls using BPF_EMIT_CALL. Such calls already
> contain helper offset relative to __bpf_call_base and must bypass the
> verifier's patch_call_imm fixup, which expects BPF helper IDs rather than a
> pre-resolved offsets.
> 
> Add a finalized_call flag to bpf_insn_aux_data to mark call instructions
> with resolved offsets so the verifier can skip patch_call_imm fixup for
> these calls.
> 
> Note that the target of BPF_EMIT_CALL should be wrapped with BPF_CALL_x to
> prevent an ABI mismatch between BPF and C on 32-bit architectures.
> 
> Suggested-by: Alexei Starovoitov <ast@...nel.org>
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>
> ---

Reviewed-by: Eduard Zingerman <eddyz87@...il.com>

[...]

> @@ -21867,6 +21880,8 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
>  			ret = add_kfunc_in_insns(env, insn_buf, cnt - 1);
>  			if (ret < 0)
>  				return ret;
> +
> +			mark_helper_calls_finalized(env, 0, cnt - 1);

Note to reviewers:
  `cnt - 1` is because each prologue-generating function does
  `*insn++ = prog->insnsi[0];` in the end. Confusing every time.

>  		}
>  	}
>  
> @@ -21880,6 +21895,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
>  
>  	for (i = 0; i < insn_cnt; i++, insn++) {
>  		bpf_convert_ctx_access_t convert_ctx_access;
> +		bool is_epilogue = false;

Nit: maybe rename this to finalize_helper_calls and untie from epilogue_idx?
     In case someone would want to add a kfunc call not in an epilogue?

>  		u8 mode;
>  
>  		if (env->insn_aux_data[i + delta].nospec) {

[...]

@@ -23477,6 +23497,9 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
 			goto next_insn;
 		}
 patch_call_imm:
+		if (env->insn_aux_data[i + delta].finalized_call)
+			goto next_insn;
+

Note: This jumps over env->ops->get_func_proto() call.
      Which means that env->ops will not have means to specialize
      helper calls inside pro/epilogue. Not a problem at the moment,
      as the only helper called seem to be 'bpf_skb_pull_data' and
      it does not appear to have alternative implementations.
      Something to keep in mind when extending the code, though.

 		fn = env->ops->get_func_proto(insn->imm, env->prog);
 		/* all functions that have prototype and verifier allowed
 		 * programs to call them, must be real in-kernel functions
[...]