Re: [PATCH bpf-next 1/2] bpf: Add bitwise tracking for BPF_END

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-02-02 at 21:35 +0800, Tianci Cao wrote:
> This patch implements bitwise tracking (tnum analysis) for BPF_END
> (byte swap) operation.
> 
> Currently, the BPF verifier does not track value for BPF_END operation,
> treating the result as completely unknown. This limits the verifier's
> ability to prove safety of programs that perform endianness conversions,
> which are common in networking code.
> 
> For example, the following code pattern for port number validation:
> 
> int test(struct pt_regs *ctx) {
>     __u64 x = bpf_get_prandom_u32();
>     x &= 0x3f00;           // Range: [0, 0x3f00], var_off: (0x0; 0x3f00)
>     x = bswap16(x);        // Should swap to range [0, 0x3f], var_off: (0x0; 0x3f)
>     if (x > 0x3f) goto trap;
>     return 0;
> trap:
>     return *(u64 *)NULL;   // Should be unreachable
> }
> 
> Currently generates verifier output:
> 
> 1: (54) w0 &= 16128                   ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=16128,var_off=(0x0; 0x3f00))
> 2: (d7) r0 = bswap16 r0               ; R0=scalar()
> 3: (25) if r0 > 0x3f goto pc+2        ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=63,var_off=(0x0; 0x3f))
> 
> Without this patch, even though the verifier knows `x` has certain bits
> set, after bswap16, it loses all tracking information and treats port
> as having a completely unknown value [0, 65535].
> 
> According to the BPF instruction set[1], there are 3 kinds of BPF_END:
> 
> 1. `bswap(16|32|64)`: opcode=0xd7 (BPF_END | BPF_ALU64 | BPF_TO_LE)
>    - do unconditional swap
> 2. `le(16|32|64)`: opcode=0xd4 (BPF_END | BPF_ALU | BPF_TO_LE)
>    - on big-endian: do swap
>    - on little-endian: truncation (16/32-bit) or no-op (64-bit)
> 3. `be(16|32|64)`: opcode=0xdc (BPF_END | BPF_ALU | BPF_TO_BE)
>    - on little-endian: do swap
>    - on big-endian: truncation (16/32-bit) or no-op (64-bit)
> 
> Since BPF_END operations are inherently bit-wise permutations, tnum
> (bitwise tracking) offers the most efficient and precise mechanism
> for value analysis. By implementing `tnum_bswap16`, `tnum_bswap32`,
> and `tnum_bswap64`, we can derive exact `var_off` values concisely,
> directly reflecting the bit-level changes.
> 
> Here is the overview of changes:
> 
> 1. In `tnum_bswap(16|32|64)` (kernel/bpf/tnum.c):
> 
> Call `swab(16|32|64)` function on the value and mask of `var_off`, and
> do truncation for 16/32-bit cases.
> 
> 2. In `adjust_scalar_min_max_vals` (kernel/bpf/verifier.c):
> 
> Call helper function `scalar_byte_swap`.
> - Only do byte swap when
>   * alu64 (unconditional swap) OR
>   * switching between big-endian and little-endian machines.
> - If need do byte swap:
>   * Firstly call `tnum_bswap(16|32|64)` to update `var_off`.
>   * Then reset the bound since byte swap scrambles the range.
> - For 16/32-bit cases, truncate dst register to match the swapped size.
> 
> This enables better verification of networking code that frequently uses
> byte swaps for protocol processing, reducing false positive rejections.
> 
> [1] https://www.kernel.org/doc/Documentation/bpf/standardization/instruction-set.rst
> 
> Co-developed-by: Shenghao Yuan <shenghaoyuan0928@163.com>
> Signed-off-by: Shenghao Yuan <shenghaoyuan0928@163.com>
> Co-developed-by: Yazhou Tang <tangyazhou518@outlook.com>
> Signed-off-by: Yazhou Tang <tangyazhou518@outlook.com>
> Signed-off-by: Tianci Cao <ziye@zju.edu.cn>
> ---

Hi Tianci, the code looks correct, a single nit below.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

> @@ -15986,12 +16029,19 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
>  		else
>  			scalar_min_max_arsh(dst_reg, &src_reg);
>  		break;
> +	case BPF_END:
> +		scalar_byte_swap(dst_reg, insn);
> +		break;
>  	default:
>  		break;
>  	}
>  
> -	/* ALU32 ops are zero extended into 64bit register */
> -	if (alu32)
> +	/*
> +	 * ALU32 ops are zero extended into 64bit register.
> +	 * BPF_END is already handled inside the helper (truncation),
> +	 * so skip zext here.
> +	 */
> +	if (alu32 && opcode != BPF_END)

Nit: zext after scalar_byte_swap() won't change anything, right?
     If so, I'd just avoid the special case and skip 'opcode != BPF_END'.

>  		zext_32_to_64(dst_reg);
>  	reg_bounds_sync(dst_reg);
>  	return 0;

[...]