[PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding

[PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding

[George Hu]

Emit "xor eax, eax" instead of "xor rax, rax".
In 64-bit mode, zeroing EAX implicitly clears RAX, and the 32-bit
form encodes one byte smaller while keeping identical semantics.

Signed-off-by: George Hu <integral@archlinux.org>
---
 arch/x86/net/bpf_jit_comp.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 9fbef7504e51..2e3c8e9861a4 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -579,8 +579,11 @@ static void emit_prologue(u8 **pprog, u8 *ip, u32 stack_depth, bool ebpf_from_cb
 		if (tail_call_reachable && !is_subprog)
 			/* When it's the entry of the whole tailcall context,
 			 * zeroing rax means initialising tail_call_cnt.
+			 *
+			 * xor eax, eax
+			 * equivalent to 'xor rax, rax', but one byte less
 			 */
-			EMIT3(0x48, 0x31, 0xC0); /* xor rax, rax */
+			EMIT2(0x31, 0xC0);
 		else
 			/* Keep the same instruction layout. */
 			emit_nops(&prog, 3);     /* nop3 */
-- 
2.55.0

Re: [PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: prologue size reduction truncates stack pointer in tail calls
--

commit b074cc264a81306406896f5f166974e4a1d9467f
Author: George Hu <integral@archlinux.org>

bpf, x86: use 32-bit zero idiom for shorter encoding

This commit reduces the BPF prologue size by changing "xor rax, rax"
to "xor eax, eax", saving one byte in the generated instructions.

> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index de7515ea1beae..a62317b78df1e 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -551,8 +551,11 @@ static void emit_prologue(u8 **pprog, u8 *ip, u32 stack_depth, bool ebpf_from_cb
>  		if (tail_call_reachable && !is_subprog)
>  			/* When it's the entry of the whole tailcall context,
>  			 * zeroing rax means initialising tail_call_cnt.
> +			 *
> +			 * xor eax, eax
> +			 * equivalent to 'xor rax, rax', but one byte less
>  			 */
> -			EMIT3(0x48, 0x31, 0xC0); /* xor rax, rax */
> +			EMIT2(0x31, 0xC0);

[Severity: Critical]
Does this 1-byte reduction break the hardcoded tail call offset assumption?

X86_TAIL_CALL_OFFSET is defined as (12 + ENDBR_INSN_SIZE) elsewhere in this
file. By reducing the prologue instruction size from 3 bytes to 2 bytes,
the 12-byte layout expected by the tail call jump logic appears to be broken.

During a tail call jump, this 1-byte mismatch will cause the jump to land past
the intended destination, skipping the 0x48 REX.W prefix of the subsequent
instruction:

    EMIT3_off32(0x48, 0x81, 0xEC, round_up(stack_depth, 8));

The CPU would then decode the remainder as a 32-bit sub esp instruction,
which zeroes the upper 32 bits of the stack pointer (rsp). This points the
stack into unprivileged user-space memory, potentially allowing local
privilege escalation.

>  		else
>  			/* Keep the same instruction layout. */
>  			emit_nops(&prog, 3);     /* nop3 */

[Severity: Critical]
Should this fallback branch also be updated to 2 bytes?

Since the tail-call reachable path above was changed to emit 2 bytes, leaving
this as a 3-byte NOP destroys the consistent instruction layout between
tail-call-reachable and non-tail-call-reachable programs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924160154.12807-1-integral@archlinux.org?part=1

Re: [PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding

[Alexei Starovoitov]

On Fri, Sep 25, 2026 at 12:01 AM George Hu <integral@archlinux.org> wrote:
> -			EMIT3(0x48, 0x31, 0xC0); /* xor rax, rax */
> +			EMIT2(0x31, 0xC0);
>  		else
>  			/* Keep the same instruction layout. */
>  			emit_nops(&prog, 3);     /* nop3 */

No. This breaks tail calls.

xor is 3 bytes to match nop3 in the else branch.
Every tail call jumps to prog->bpf_func + X86_TAIL_CALL_OFFSET of
the target prog, and that is a constant 12 + ENDBR_INSN_SIZE.
With 2 byte xor a tail call into a prog that does tail calls itself
lands one byte into the insn that follows 'mov rbp, rsp'.
Without IBT it is 'sub rsp, imm32' 48 81 EC. Without the first byte
it becomes 'sub esp, imm32' and clears the upper 32 bits of rsp.
With IBT it's the middle of endbr64.

It was xor eax, eax, nop2 and offset 11 before
commit 116e04ba1459 ("bpf, x64: Fix tailcall hierarchy").

pw-bot: cr