[PATCH] uprobes/x86: Emulate ENDBR as a NOP

[PATCH] uprobes/x86: Emulate ENDBR as a NOP

[Hang Zhengyang via B4 Relay]

From: Hang Zhengyang <hang.zhengyang1010@gmail.com>

A uprobe on ENDBR64 is single-stepped, so it takes two traps instead of
one: insn_is_nop() doesn't recognize ENDBR, and it isn't a branch or a
push either.  That makes the most common case slow.  With
-fcf-protection, the default for gcc on Ubuntu, every function starts
with ENDBR64, so every uprobe on a function entry pays for the
single-step.  PUSH had the same problem until commit e7ed9d9bd037
("uprobes/x86: Emulate push insns for uprobe on x86").

Userspace IBT is not supported, so ENDBR is just a NOP in user mode.
Emulate it like the other NOPs.  Don't use is_endbr() for the check: it
always returns false without CONFIG_X86_KERNEL_IBT.  If userspace IBT
is ever enabled, uprobes on ENDBR will need rework anyway, since the
int3 replaces the ENDBR at an indirect branch target.

The numbers below are from the selftests/bpf trigger benchmarks, with
an extra target that starts with ENDBR64 (the existing ones are built
with __nocf_check, so they don't have it).  On a Ryzen 7 PRO 5850U,
without this patch, a probe on ENDBR64 is as slow as a single-stepped
one:

             nop       endbr64   ret (single-step)
  uprobe     1.33 M/s  0.65 M/s  0.65 M/s
  uretprobe  0.66 M/s  0.43 M/s  0.43 M/s

With this patch ENDBR64 is emulated like a NOP.  I could only boot the
patched kernel in a KVM guest, where uprobe went from 0.19 to 0.99 M/s
(nop: 1.00) and uretprobe from 0.17 to 0.61 M/s (nop: 0.61).

Signed-off-by: Hang Zhengyang <hang.zhengyang1010@gmail.com>
---
Found and measured with Claude; I reviewed it and ran the measurement.
---
 arch/x86/kernel/uprobes.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 0f60c0d076b6..879ce918ebea 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -1484,13 +1484,28 @@ static const struct uprobe_xol_ops push_xol_ops = {
 	.emulate  = push_emulate_op,
 };
 
+/*
+ * ENDBR64/ENDBR32 (f3 0f 1e fa/fb).  Userspace IBT is not supported, so
+ * in a user task they are NOPs, and they start most functions in
+ * binaries built with -fcf-protection.  Revisit if userspace IBT is
+ * ever enabled.
+ */
+static bool insn_is_endbr(struct insn *insn)
+{
+	return insn->length == 4 &&
+	       insn->prefixes.nbytes == 1 && insn->prefixes.bytes[0] == 0xf3 &&
+	       insn->opcode.nbytes == 2 && insn->opcode.bytes[0] == 0x0f &&
+	       insn->opcode.bytes[1] == 0x1e &&
+	       (insn->modrm.bytes[0] & ~1) == 0xfa;
+}
+
 /* Returns -ENOSYS if branch_xol_ops doesn't handle this insn */
 static int branch_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
 {
 	u8 opc1 = OPCODE1(insn);
 	insn_byte_t p;
 
-	if (insn_is_nop(insn))
+	if (insn_is_nop(insn) || insn_is_endbr(insn))
 		goto setup;
 
 	switch (opc1) {

---
base-commit: 9d66f26fefacebfeed15de31c1123451a17ff119
change-id: 20261112-uprobe-endbr-7c7ab1baa191

Best regards,
-- 
Hang Zhengyang <hang.zhengyang1010@gmail.com>

Re: [PATCH] uprobes/x86: Emulate ENDBR as a NOP

[Peter Zijlstra]

On Thu, Nov 12, 2026 at 01:26:18PM +0800, Hang Zhengyang via B4 Relay wrote:
> From: Hang Zhengyang <hang.zhengyang1010@gmail.com>
> 
> A uprobe on ENDBR64 is single-stepped, so it takes two traps instead of
> one: insn_is_nop() doesn't recognize ENDBR, and it isn't a branch or a
> push either.  That makes the most common case slow.  With
> -fcf-protection, the default for gcc on Ubuntu, every function starts
> with ENDBR64, so every uprobe on a function entry pays for the
> single-step.  PUSH had the same problem until commit e7ed9d9bd037
> ("uprobes/x86: Emulate push insns for uprobe on x86").
> 
> Userspace IBT is not supported, so ENDBR is just a NOP in user mode.
> Emulate it like the other NOPs.  Don't use is_endbr() for the check: it
> always returns false without CONFIG_X86_KERNEL_IBT.  If userspace IBT
> is ever enabled, uprobes on ENDBR will need rework anyway, since the
> int3 replaces the ENDBR at an indirect branch target.
> 
> The numbers below are from the selftests/bpf trigger benchmarks, with
> an extra target that starts with ENDBR64 (the existing ones are built
> with __nocf_check, so they don't have it).  On a Ryzen 7 PRO 5850U,
> without this patch, a probe on ENDBR64 is as slow as a single-stepped
> one:
> 
>              nop       endbr64   ret (single-step)
>   uprobe     1.33 M/s  0.65 M/s  0.65 M/s
>   uretprobe  0.66 M/s  0.43 M/s  0.43 M/s
> 
> With this patch ENDBR64 is emulated like a NOP.  I could only boot the
> patched kernel in a KVM guest, where uprobe went from 0.19 to 0.99 M/s
> (nop: 1.00) and uretprobe from 0.17 to 0.61 M/s (nop: 0.61).
> 
> Signed-off-by: Hang Zhengyang <hang.zhengyang1010@gmail.com>
> ---

Uh, no. We must not allow uprobe on ENDBR. If we ever get userspace IBT
(people are actually looking at that), then putting a probe on it will
make indirect function calls #CP.

None of this makes sense.

Re: [PATCH] uprobes/x86: Emulate ENDBR as a NOP

[Hang Zhengyang]

On Thu, Nov 12, 2026 at 09:04:06AM +0100, Peter Zijlstra wrote:
> Uh, no. We must not allow uprobe on ENDBR. If we ever get userspace IBT
> (people are actually looking at that), then putting a probe on it will
> make indirect function calls #CP.

You're right, I missed that. I'll drop this patch.

Re: [PATCH] uprobes/x86: Emulate ENDBR as a NOP

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

> uprobes/x86: Emulate ENDBR as a NOP

TL;DR: Design question: Peter Zijlstra objected on v1 that probing ENDBR would
cause #CP on indirect calls if userspace IBT arrives; the author agreed to
drop it, yet the patch still emulates ENDBR as a NOP.

> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c

[ ... ]

> +/*
> + * ENDBR64/ENDBR32 (f3 0f 1e fa/fb).  Userspace IBT is not supported, so
> + * in a user task they are NOPs, and they start most functions in
> + * binaries built with -fcf-protection.  Revisit if userspace IBT is
> + * ever enabled.
> + */
> +static bool insn_is_endbr(struct insn *insn)
> +{
> +	return insn->length == 4 &&
> +	       insn->prefixes.nbytes == 1 && insn->prefixes.bytes[0] == 0xf3 &&
> +	       insn->opcode.nbytes == 2 && insn->opcode.bytes[0] == 0x0f &&
> +	       insn->opcode.bytes[1] == 0x1e &&
> +	       (insn->modrm.bytes[0] & ~1) == 0xfa;
> +}
> +
>  /* Returns -ENOSYS if branch_xol_ops doesn't handle this insn */
>  static int branch_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
>  {
>  	u8 opc1 = OPCODE1(insn);
>  	insn_byte_t p;
>
> -	if (insn_is_nop(insn))
> +	if (insn_is_nop(insn) || insn_is_endbr(insn))
>  		goto setup;

Peter Zijlstra objected to this approach on the v1 thread:

  Uh, no. We must not allow uprobe on ENDBR. If we ever get userspace
  IBT (people are actually looking at that), then putting a probe on it
  will make indirect function calls #CP.

Has that objection been addressed?  The thread indicates the author agreed
and planned to drop the patch, yet this commit still emulates ENDBR as a
NOP in branch_setup_xol_ops().

Link: https://lore.kernel.org/all/20261112080406.GA2668804@noisy.programming.kicks-ass.net/


---
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/43353937212