[PATCH bpf-next 0/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc JITs

[PATCH bpf-next 0/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc JITs

[Nicholas Dudar]

The parisc BPF JITs emit unsigned divide and remainder for signed
BPF_DIV and BPF_MOD (off == 1) on the 64-bit and 32-bit JITs, so
neither implements signed BPF_SDIV and BPF_SMOD. Signed div/mod
return an unsigned result for negative operands rather than the
verifier's and the interpreter's signed result.

Patch 1 adds signed support to the parisc64 JIT and the shared signed
64-bit helpers (hppa_sdiv64/hppa_sdiv64_rem) in bpf_jit_core.c. Patch
2 adds it to the parisc32 JIT, using those helpers for the 64-bit path
and the $$divI/$$remI signed millicode for the 32-bit path.

Both were tested with test_bpf on qemu-system-hppa; the signed div/mod
cases fail before and pass after.

Nicholas Dudar (2):
  bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT
  bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

 arch/parisc/net/bpf_jit.h        |  2 ++
 arch/parisc/net/bpf_jit_comp32.c | 29 +++++++++++++++++---------
 arch/parisc/net/bpf_jit_comp64.c | 35 ++++++++++++++++++++++++--------
 arch/parisc/net/bpf_jit_core.c   | 14 +++++++++++++
 4 files changed, 61 insertions(+), 19 deletions(-)


base-commit: 1d91ea01185656ac3ee63c5f9f6f8bde3c746b3d
-- 
2.34.1

[PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Nicholas Dudar]

emit_call_libgcc_ll() zero-extends the ALU32 operands and calls the
unsigned hppa_div64()/hppa_div64_rem() helpers regardless of the BPF
instruction's signedness, so the parisc64 JIT does not implement
signed BPF_SDIV and BPF_SMOD (off == 1). Signed ALU32 and ALU64
div/mod get an unsigned quotient and remainder rather than the
verifier's and the interpreter's signed result for negative operands.

Add hppa_sdiv64()/hppa_sdiv64_rem() wrapping div64_s64(), thread
is_signed = (insn->off == 1) through the div/mod emit sites, and on the
signed path sign-extend the ALU32 operands (and the immediate divisor)
instead of zero-extending them before calling the signed helpers.
bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
of the instruction stream before the JIT runs.

Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Assisted-by: Claude:claude-opus-4-8
---
 arch/parisc/net/bpf_jit.h        |  2 ++
 arch/parisc/net/bpf_jit_comp64.c | 35 ++++++++++++++++++++++++--------
 arch/parisc/net/bpf_jit_core.c   | 14 +++++++++++++
 3 files changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/parisc/net/bpf_jit.h b/arch/parisc/net/bpf_jit.h
index 8b8896959f04..074115c93c90 100644
--- a/arch/parisc/net/bpf_jit.h
+++ b/arch/parisc/net/bpf_jit.h
@@ -467,6 +467,8 @@ static inline u32 hppa_t21_insn(u8 opcode, u8 r2, u8 r1, u8 ext8, u8 t)
 
 u64 hppa_div64(u64 div, u64 divisor);
 u64 hppa_div64_rem(u64 div, u64 divisor);
+u64 hppa_sdiv64(u64 div, u64 divisor);
+u64 hppa_sdiv64_rem(u64 div, u64 divisor);
 
 /* Helper functions that emit HPPA instructions when possible. */
 
diff --git a/arch/parisc/net/bpf_jit_comp64.c b/arch/parisc/net/bpf_jit_comp64.c
index 54b0d5e25e02..c326fa737ec8 100644
--- a/arch/parisc/net/bpf_jit_comp64.c
+++ b/arch/parisc/net/bpf_jit_comp64.c
@@ -502,14 +502,19 @@ static void emit_call(u64 addr, bool fixed, struct hppa_jit_context *ctx)
 	emit_hppa_copy(HPPA_REG_RET0, regmap[BPF_REG_0], ctx);
 }
 
-static void emit_call_libgcc_ll(void *func, const s8 arg0,
-		const s8 arg1, u8 opcode, struct hppa_jit_context *ctx)
+static void emit_call_libgcc_ll(void *func, const s8 arg0, const s8 arg1,
+		u8 opcode, bool is_signed, struct hppa_jit_context *ctx)
 {
 	u64 func_addr;
 
 	if (BPF_CLASS(opcode) == BPF_ALU) {
-		emit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);
-		emit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);
+		if (is_signed) {
+			emit_hppa64_sext32(arg0, HPPA_REG_ARG0, ctx);
+			emit_hppa64_sext32(arg1, HPPA_REG_ARG1, ctx);
+		} else {
+			emit_hppa64_zext32(arg0, HPPA_REG_ARG0, ctx);
+			emit_hppa64_zext32(arg1, HPPA_REG_ARG1, ctx);
+		}
 	} else {
 		emit_hppa_copy(arg0, HPPA_REG_ARG0, ctx);
 		emit_hppa_copy(arg1, HPPA_REG_ARG1, ctx);
@@ -600,6 +605,8 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 	u8 rd = -1, rs = -1, code = insn->code;
 	s16 off = insn->off;
 	s32 imm = insn->imm;
+	bool is_signed;
+	void *func;
 
 	init_regs(&rd, &rs, insn, ctx);
 
@@ -656,29 +663,39 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 		fallthrough;
 	case BPF_ALU | BPF_MUL | BPF_X:
 	case BPF_ALU64 | BPF_MUL | BPF_X:
-		emit_call_libgcc_ll(__muldi3, rd, rs, code, ctx);
+		emit_call_libgcc_ll(__muldi3, rd, rs, code, false, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
 	case BPF_ALU | BPF_DIV | BPF_K:
 	case BPF_ALU64 | BPF_DIV | BPF_K:
-		emit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);
+		is_signed = (off == 1);
+		emit_imm(HPPA_REG_T1,
+			 is64 || is_signed ? (s64)(s32)imm : (u32)imm,
+			 HPPA_REG_T2, ctx);
 		rs = HPPA_REG_T1;
 		fallthrough;
 	case BPF_ALU | BPF_DIV | BPF_X:
 	case BPF_ALU64 | BPF_DIV | BPF_X:
-		emit_call_libgcc_ll(&hppa_div64, rd, rs, code, ctx);
+		is_signed = (off == 1);
+		func = is_signed ? &hppa_sdiv64 : &hppa_div64;
+		emit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
 	case BPF_ALU | BPF_MOD | BPF_K:
 	case BPF_ALU64 | BPF_MOD | BPF_K:
-		emit_imm(HPPA_REG_T1, is64 ? (s64)(s32)imm : (u32)imm, HPPA_REG_T2, ctx);
+		is_signed = (off == 1);
+		emit_imm(HPPA_REG_T1,
+			 is64 || is_signed ? (s64)(s32)imm : (u32)imm,
+			 HPPA_REG_T2, ctx);
 		rs = HPPA_REG_T1;
 		fallthrough;
 	case BPF_ALU | BPF_MOD | BPF_X:
 	case BPF_ALU64 | BPF_MOD | BPF_X:
-		emit_call_libgcc_ll(&hppa_div64_rem, rd, rs, code, ctx);
+		is_signed = (off == 1);
+		func = is_signed ? &hppa_sdiv64_rem : &hppa_div64_rem;
+		emit_call_libgcc_ll(func, rd, rs, code, is_signed, ctx);
 		if (!is64 && !aux->verifier_zext)
 			emit_zext_32(rd, ctx);
 		break;
diff --git a/arch/parisc/net/bpf_jit_core.c b/arch/parisc/net/bpf_jit_core.c
index 172770132440..a2f93202a2ef 100644
--- a/arch/parisc/net/bpf_jit_core.c
+++ b/arch/parisc/net/bpf_jit_core.c
@@ -190,3 +190,17 @@ u64 hppa_div64_rem(u64 div, u64 divisor)
 	div64_u64_rem(div, divisor, &rem);
 	return rem;
 }
+
+u64 hppa_sdiv64(u64 div, u64 divisor)
+{
+	s64 sdiv = div64_s64((s64)div, (s64)divisor);
+
+	return (u64)sdiv;
+}
+
+u64 hppa_sdiv64_rem(u64 div, u64 divisor)
+{
+	s64 sdiv = div64_s64((s64)div, (s64)divisor);
+
+	return (u64)((s64)div - sdiv * (s64)divisor);
+}
-- 
2.34.1

[PATCH bpf-next 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

[Nicholas Dudar]

emit_alu_r32() and emit_alu_r64() call the unsigned millicode
($$divU/$$remU) and libgcc-style (hppa_div64()/hppa_div64_rem())
divide/remainder helpers for BPF_DIV and BPF_MOD regardless of the
BPF instruction's signedness, so the parisc32 JIT does not implement
signed BPF_SDIV and BPF_SMOD (off == 1). Signed ALU32 and ALU64
div/mod get an unsigned quotient and remainder rather than the
verifier's and the interpreter's signed result for negative operands.

Thread is_signed = (insn->off == 1) through emit_alu_r32()/
emit_alu_r64(), and on the signed path use the $$divI/$$remI signed
millicode routines (32-bit) or the hppa_sdiv64()/hppa_sdiv64_rem()
helpers added in patch 1 (64-bit) instead of their unsigned
counterparts. $$divI and $$remI are extern-declared and exported next
to $$divU/$$remU in arch/parisc/kernel/parisc_ksyms.c.
bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
of the instruction stream before the JIT runs.

Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Assisted-by: Claude:claude-opus-4-8
---
 arch/parisc/net/bpf_jit_comp32.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/parisc/net/bpf_jit_comp32.c b/arch/parisc/net/bpf_jit_comp32.c
index 5ff0cf925fe9..eea0a34a3bfe 100644
--- a/arch/parisc/net/bpf_jit_comp32.c
+++ b/arch/parisc/net/bpf_jit_comp32.c
@@ -321,6 +321,8 @@ static void bpf_put_reg32(const s8 *reg, const s8 *src,
 extern void $$mulI(void);
 extern void $$divU(void);
 extern void $$remU(void);
+extern void $$divI(void);
+extern void $$remI(void);
 
 static void emit_call_millicode(void *func, const s8 arg0,
 		const s8 arg1, u8 opcode, struct hppa_jit_context *ctx)
@@ -562,12 +564,14 @@ static void emit_alu_i32(const s8 *dst, s32 imm,
 }
 
 static void emit_alu_r64(const s8 *dst, const s8 *src,
-			 struct hppa_jit_context *ctx, const u8 op)
+			 struct hppa_jit_context *ctx, const u8 op,
+			 bool is_signed)
 {
 	const s8 *tmp1 = regmap[TMP_REG_1];
 	const s8 *tmp2 = regmap[TMP_REG_2];
 	const s8 *rd;
 	const s8 *rs = bpf_get_reg64(src, tmp2, ctx);
+	void *func;
 
 	if (op == BPF_MOV)
 		rd = bpf_get_reg64_ref(dst, tmp1, false, ctx);
@@ -604,10 +608,12 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,
 		emit_call_libgcc_ll(__muldi3, rd, rs, op, ctx);
 		break;
 	case BPF_DIV:
-		emit_call_libgcc_ll(&hppa_div64, rd, rs, op, ctx);
+		func = is_signed ? &hppa_sdiv64 : &hppa_div64;
+		emit_call_libgcc_ll(func, rd, rs, op, ctx);
 		break;
 	case BPF_MOD:
-		emit_call_libgcc_ll(&hppa_div64_rem, rd, rs, op, ctx);
+		func = is_signed ? &hppa_sdiv64_rem : &hppa_div64_rem;
+		emit_call_libgcc_ll(func, rd, rs, op, ctx);
 		break;
 	case BPF_LSH:
 		emit_call_libgcc_ll(__ashldi3, rd, rs, op, ctx);
@@ -630,7 +636,8 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,
 }
 
 static void emit_alu_r32(const s8 *dst, const s8 *src,
-			 struct hppa_jit_context *ctx, const u8 op)
+			 struct hppa_jit_context *ctx, const u8 op,
+			 bool is_signed)
 {
 	const s8 *tmp1 = regmap[TMP_REG_1];
 	const s8 *tmp2 = regmap[TMP_REG_2];
@@ -666,10 +673,12 @@ static void emit_alu_r32(const s8 *dst, const s8 *src,
 		emit_call_millicode($$mulI, lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_DIV:
-		emit_call_millicode($$divU, lo(rd), lo(rs), op, ctx);
+		emit_call_millicode(is_signed ? $$divI : $$divU,
+				    lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_MOD:
-		emit_call_millicode($$remU, lo(rd), lo(rs), op, ctx);
+		emit_call_millicode(is_signed ? $$remI : $$remU,
+				    lo(rd), lo(rs), op, ctx);
 		break;
 	case BPF_LSH:
 		emit(hppa_subi(0x1f, lo(rs), HPPA_REG_T0), ctx);
@@ -1163,12 +1172,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 			emit_imm32(tmp2, imm, ctx);
 			src = tmp2;
 		}
-		emit_alu_r64(dst, src, ctx, BPF_OP(code));
+		emit_alu_r64(dst, src, ctx, BPF_OP(code), off == 1);
 		break;
 
 	/* dst = -dst */
 	case BPF_ALU64 | BPF_NEG:
-		emit_alu_r64(dst, tmp2, ctx, BPF_OP(code));
+		emit_alu_r64(dst, tmp2, ctx, BPF_OP(code), false);
 		break;
 
 	case BPF_ALU64 | BPF_MOV | BPF_K:
@@ -1211,7 +1220,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 			emit_imm32(tmp2, imm, ctx);
 			src = tmp2;
 		}
-		emit_alu_r32(dst, src, ctx, BPF_OP(code));
+		emit_alu_r32(dst, src, ctx, BPF_OP(code), off == 1);
 		break;
 
 	/* dst = dst OP imm */
@@ -1236,7 +1245,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
 		 * src is ignored---choose tmp2 as a dummy register since it
 		 * is not on the stack.
 		 */
-		emit_alu_r32(dst, tmp2, ctx, BPF_OP(code));
+		emit_alu_r32(dst, tmp2, ctx, BPF_OP(code), false);
 		break;
 
 	/* dst = BSWAP##imm(dst) */
-- 
2.34.1

Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch implements BPF_SDIV and BPF_SMOD for the 64-bit PA-RISC JIT but omits the 32-bit JIT, causing signed divisions to be silently miscompiled as unsigned.
--

--- Patch [1]: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT ---
commit 5e5d75e62e2afee7aac7d5510ab28785201de9f5
Author: Nicholas Dudar <main.kalliope@gmail.com>

bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

This commit adds support for signed division and modulo (BPF_SDIV and
BPF_SMOD) to the 64-bit PA-RISC BPF JIT. It passes the signedness check
down to the emission functions and introduces signed libgcc helper
wrappers.

> bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Severity: High]
This is a pre-existing issue, but does the 32-bit PA-RISC JIT still
miscompile signed divisions as unsigned?

While this patch correctly implements BPF_SDIV and BPF_SMOD for the 64-bit
JIT, arch/parisc/net/bpf_jit_comp32.c appears to still unconditionally
accept these instructions without checking if insn->off == 1.

In arch/parisc/net/bpf_jit_comp32.c:bpf_jit_emit_insn():

    case BPF_ALU | BPF_DIV | BPF_X:
    case BPF_ALU | BPF_DIV | BPF_K:
    case BPF_ALU | BPF_MOD | BPF_X:
    case BPF_ALU | BPF_MOD | BPF_K:
        /* ... */
        emit_alu_r32(dst, src, ctx, BPF_OP(code));

And then in emit_alu_r32():

    case BPF_DIV:
        emit_call_millicode($$divU, lo(rd), lo(rs), op, ctx);
        break;
    case BPF_MOD:
        emit_call_millicode($$remU, lo(rd), lo(rs), op, ctx);
        break;

Because the JIT silently compiles signed division as unsigned ($$divU),
and the eBPF verifier calculates memory bounds assuming a signed result,
could this verifier-JIT desynchronization be exploited to bypass bounds
checks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717190544.257306-1-main.kalliope@gmail.com?part=1

Re: [PATCH bpf-next 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The parisc32 JIT silently miscompiles the BPF_MOVSX (move with sign extension) instruction, treating it as a standard move.
- [High] `emit_call_libgcc_ll()` swaps the high and low 32-bit words of 64-bit arguments when passing them to libgcc helpers.
--

--- Patch [2]: [PATCH bpf-next 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT ---
commit ef16e681a3d01d651d08cd8250b0ccd28e9d3647
Author: Nicholas Dudar <main.kalliope@gmail.com>

bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

emit_alu_r32() and emit_alu_r64() call the unsigned millicode
($$divU/$$remU) and libgcc-style (hppa_div64()/hppa_div64_rem())
divide/remainder helpers for BPF_DIV and BPF_MOD regardless of the
BPF instruction's signedness, so the parisc32 JIT does not implement
signed BPF_SDIV and BPF_SMOD (off == 1). Signed ALU32 and ALU64
div/mod get an unsigned quotient and remainder rather than the
verifier's and the interpreter's signed result for negative operands.

Thread is_signed = (insn->off == 1) through emit_alu_r32()/
emit_alu_r64(), and on the signed path use the $$divI/$$remI signed
millicode routines (32-bit) or the hppa_sdiv64()/hppa_sdiv64_rem()
helpers added in patch 1 (64-bit) instead of their unsigned
counterparts. $$divI and $$remI are extern-declared and exported next
to $$divU/$$remU in arch/parisc/kernel/parisc_ksyms.c.
bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
of the instruction stream before the JIT runs.

> diff --git a/arch/parisc/net/bpf_jit_comp32.c b/arch/parisc/net/bpf_jit_comp32.c
> index 5ff0cf925fe95..eea0a34a3bfee 100644
> --- a/arch/parisc/net/bpf_jit_comp32.c
> +++ b/arch/parisc/net/bpf_jit_comp32.c
> @@ -562,12 +564,14 @@ static void emit_alu_i32(const s8 *dst, s32 imm,
>  }
>  
>  static void emit_alu_r64(const s8 *dst, const s8 *src,
> -			 struct hppa_jit_context *ctx, const u8 op)
> +			 struct hppa_jit_context *ctx, const u8 op,
> +			 bool is_signed)
>  {
>  	const s8 *tmp1 = regmap[TMP_REG_1];
>  	const s8 *tmp2 = regmap[TMP_REG_2];
>  	const s8 *rd;
>  	const s8 *rs = bpf_get_reg64(src, tmp2, ctx);
> +	void *func;
>  
>  	if (op == BPF_MOV)
>  		rd = bpf_get_reg64_ref(dst, tmp1, false, ctx);
> @@ -604,10 +608,12 @@ static void emit_alu_r64(const s8 *dst, const s8 *src,
>  		emit_call_libgcc_ll(__muldi3, rd, rs, op, ctx);
>  		break;
>  	case BPF_DIV:
> -		emit_call_libgcc_ll(&hppa_div64, rd, rs, op, ctx);
> +		func = is_signed ? &hppa_sdiv64 : &hppa_div64;
> +		emit_call_libgcc_ll(func, rd, rs, op, ctx);

[Severity: High]
This is a pre-existing issue, but does emit_call_libgcc_ll() swap the high
and low 32-bit words of 64-bit arguments when passing them to libgcc helpers?

For example, when calling hppa_sdiv64, emit_call_libgcc_ll() places the least
significant word (lo) into the first argument register (HPPA_REG_ARG0) and the
most significant word (hi) into the second (HPPA_REG_ARG1):

arch/parisc/net/bpf_jit_comp32.c:emit_call_libgcc_ll() {
    ...
    emit_hppa_copy(lo(arg0), HPPA_REG_ARG0, ctx);
    emit_hppa_copy(hi(arg0), HPPA_REG_ARG1, ctx);
    emit_hppa_copy(lo(arg1), HPPA_REG_ARG2, ctx);
    emit_hppa_copy(hi(arg1), HPPA_REG_ARG3, ctx);
    ...
}

Since PA-RISC is Big Endian, shouldn't the calling convention expect the most
significant word in the first register? This seems like it would cause 64-bit
ALU operations relying on libgcc helpers to compute entirely incorrect results.

>  		break;
>  	case BPF_MOD:
> -		emit_call_libgcc_ll(&hppa_div64_rem, rd, rs, op, ctx);
> +		func = is_signed ? &hppa_sdiv64_rem : &hppa_div64_rem;
> +		emit_call_libgcc_ll(func, rd, rs, op, ctx);
>  		break;

[ ... ]

> @@ -1163,12 +1172,12 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct hppa_jit_context *ctx,
>  			emit_imm32(tmp2, imm, ctx);
>  			src = tmp2;
>  		}
> -		emit_alu_r64(dst, src, ctx, BPF_OP(code));
> +		emit_alu_r64(dst, src, ctx, BPF_OP(code), off == 1);

[Severity: High]
This is a pre-existing issue, but does emit_alu_r64() silently miscompile
BPF_MOVSX (move with sign extension)?

When bpf_jit_emit_insn() intercepts BPF_ALU64 | BPF_MOV | BPF_X and passes it
to emit_alu_r64(), it does not validate if the offset is 8, 16, or 32 for the
sign extension. Then in emit_alu_r64() for BPF_MOV, it performs a simple copy:

arch/parisc/net/bpf_jit_comp32.c:emit_alu_r64() {
    ...
    case BPF_MOV:
        emit_hppa_copy(lo(rs), lo(rd), ctx);
        emit_hppa_copy(hi(rs), hi(rd), ctx);
        break;
    ...
}

Because bpf_jit_emit_insn() returns 0 (success) instead of rejecting the
unsupported instruction, the BPF core does not fall back to the interpreter.
Could this lead to silent data corruption when a BPF program relies on sign
extension, especially if the verifier assumes the extension has occurred for
bounds checking?

>  		break;
>  
>  	/* dst = -dst */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717190544.257306-1-main.kalliope@gmail.com?part=2

Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[bot+bpf-ci]

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

> emit_call_libgcc_ll() zero-extends the ALU32 operands and calls the
> unsigned hppa_div64()/hppa_div64_rem() helpers regardless of the BPF
> instruction's signedness, so the parisc64 JIT does not implement
> signed BPF_SDIV and BPF_SMOD (off == 1). Signed ALU32 and ALU64
> div/mod get an unsigned quotient and remainder rather than the
> verifier's and the interpreter's signed result for negative operands.
>
> Add hppa_sdiv64()/hppa_sdiv64_rem() wrapping div64_s64(), thread
> is_signed = (insn->off == 1) through the div/mod emit sites, and on the
> signed path sign-extend the ALU32 operands (and the immediate divisor)
> instead of zero-extending them before calling the signed helpers.
> bpf_do_misc_fixups() rewrites the zero-divisor and INT_MIN/-1 cases out
> of the instruction stream before the JIT runs.
>
> Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>

This looks like a fix for a correctness bug that has been present since
the parisc64 eBPF JIT was first added, where signed div/mod produced an
unsigned result for negative operands.

Should this carry a Fixes: tag?

  Fixes: c95e269773b3 ("parisc: Add 64-bit eBPF JIT compiler")


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

Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Nicholas Dudar]

On Fri, Jul 17, 2026 at 19:16 UTC, sashiko-bot@kernel.org wrote:
> [High] The patch implements BPF_SDIV and BPF_SMOD for the 64-bit
> PA-RISC JIT but omits the 32-bit JIT, causing signed divisions to be
> silently miscompiled as unsigned.

This is a 2-patch series, and patch 2/2 ("bpf, parisc: Add support for
BPF_SDIV and BPF_SMOD in the parisc32 JIT") is the one that modifies
bpf_jit_comp32.c. It threads is_signed = (insn->off == 1) through
emit_alu_r32()/emit_alu_r64() and uses the $$divI/$$remI signed
millicode (ALU32) and the hppa_sdiv64()/hppa_sdiv64_rem() helpers
(ALU64) on the signed path instead of $$divU/$$remU/hppa_div64().

Patch 1/2 adds those shared helpers in bpf_jit_core.c, which is why it
does not touch bpf_jit_comp32.c. With both patches applied the parisc32
JIT returns the signed result the verifier and interpreter compute; the
ALU32/ALU64 SDIV/SMOD test_bpf cases pass.

Nicholas

Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Nicholas Dudar]

On Fri, Jul 17, 2026, bot+bpf-ci@kernel.org wrote:
> Should this carry a Fixes: tag?
>   Fixes: c95e269773b3 ("parisc: Add 64-bit eBPF JIT compiler")

Sorry, my previous reply here was meant for the earlier Sashiko bot.

On the Fixes tag: this follows the review guidance on the i386 patch to
treat these signed div/mod additions as added JIT support, target
bpf-next, and drop the Fixes tag (Pu Lehui's suggestion [1], relayed by
Kuan-Wei Chiu). The sparc64 and mips patches were sent the same way.

[1] https://lore.kernel.org/bpf/fa8a040f-64c4-484f-9538-fb0ec287639f@huawei.com/

Nicholas

Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Nicholas Dudar]

On Fri, Jul 17, 2026 at 19:16 UTC, sashiko-bot@kernel.org wrote:
> [High] The patch implements BPF_SDIV and BPF_SMOD for the 64-bit
> PA-RISC JIT but omits the 32-bit JIT, causing signed divisions to be
> silently miscompiled as unsigned.

This is a two-patch series; patch 2/2 ("bpf, parisc: Add support for
BPF_SDIV and BPF_SMOD in the parisc32 JIT") adds the parisc32 support,
threading is_signed = (insn->off == 1) through emit_alu_r32()/
emit_alu_r64() and using $$divI/$$remI and hppa_sdiv64()/
hppa_sdiv64_rem() on the signed path. Patch 1/2 provides the shared
helpers patch 2/2 uses. With both applied, the parisc32 signed div/mod
tests pass.

Nicholas

Re: [PATCH bpf-next 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT

[Nicholas Dudar]

On Fri, Jul 17, 2026 at 19:27 UTC, sashiko-bot@kernel.org wrote:
> [High] emit_call_libgcc_ll() swaps the high and low 32-bit words of
> 64-bit arguments when passing them to libgcc helpers.

It does not. I checked this directly with hppa-linux-gcc 14.3.0: for a call
with two u64 arguments, GCC places the first argument's low and high words
in %r26 and %r25, and the second's in %r24 and %r23. A u64 return uses %r28
for the high word and %r29 for the low word. This matches
emit_call_libgcc_ll() and the JIT's existing normal helper-call path.

emit_call_libgcc_ll() is also the existing path for the JIT's 64-bit
multiplication and shifts through the stock libgcc routines. Their test_bpf
cases pass, as do the ALU64 signed div/mod register and immediate-magnitude
cases added here.

> [High] The parisc32 JIT silently miscompiles the BPF_MOVSX (move with
> sign extension) instruction, treating it as a standard move.

Yes, and it is pre-existing and separate from signed div/mod. The JIT
dispatches BPF_{ALU,ALU64} | BPF_MOV | BPF_X without inspecting insn->off,
so a sign-extending move (off = 8/16/32) is emitted as a plain copy. This
patch does not touch the MOV path; the five BPF_MOVSX test_bpf cases fail
identically before and after the series. I'll address it in a separate patch.

Nicholas