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@xxxxxxxxx>
> 
> 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@xxxxxxxxx>
> ---

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.