[PATCH bpf-next v2 0/7] bpf: follow-up for scalar evolution series

[PATCH bpf-next v2 0/7] bpf: follow-up for scalar evolution series

[Eduard Zingerman]

Assorted follow-ups for the series [1]:
- Handle ARG_SCALAR and ARG_PTR_TO_DYNPTR in
  bpf_global_subprog_stack_access_bytes().
- Fixes for other nits reported by bots for the series.

Changelog v1 -> v2:
- dropped patch #1,
  "bpf: static subprogram arguments liveness should use BTF type info",
  see the v1 lore link for explanation.

v1: https://lore.kernel.org/bpf/20261010-scev-minimal-v3-followups-v1-0-6000e95ef993@gmail.com/
---
Eduard Zingerman (7):
      bpf: more precise stack liveness effects for global func params
      bpf: avoid duplicate declaration for BPF_SCEV_REGS_NUM
      bpf: reg_bounds_sync() comment fixup
      selftests/bpf: stack effects of scalar/dynptr global subprog params
      selftests/bpf: harden __msg pattern for global_callee_btf_arg
      selftests/bpf: harden __msg patterns for step_movsx_bounds_on_line
      selftests/bpf: BPF_F_ANY_ALIGNMENT for byte_array_size_spanning()

 include/linux/bpf_verifier.h                       |  3 --
 kernel/bpf/verifier.c                              |  8 ++-
 .../selftests/bpf/progs/verifier_bounds_step.c     |  4 +-
 .../bpf/progs/verifier_btf_array_access.c          |  1 +
 .../selftests/bpf/progs/verifier_live_stack.c      | 62 +++++++++++++++++++++-
 5 files changed, 70 insertions(+), 8 deletions(-)
---
base-commit: 763187dbbf83764a57d5811168ef9de7b9a60e2d
change-id: 20261010-scev-minimal-v3-followups-c1e3f247f224

[PATCH bpf-next v2 1/7] bpf: more precise stack liveness effects for global func params

[Eduard Zingerman]

The following types can be returned by the btf_prepare_func_args():
- ARG_PTR_TO_CTX
- ARG_PTR_TO_BTF_ID (+ flags)
- ARG_PTR_TO_MEM (+ flags)
- ARG_PTR_TO_ARENA
- ARG_PTR_TO_DYNPTR
- ARG_SCALAR

Of these, valid programs can pass frame pointer only as
ARG_PTR_TO_{MEM,BTF_ID,DYNPTR}. Additionally, pointer arithmetic
allows the following trick:

  0: (bf) r1 = r10
  1: (07) r1 += -8
  2: (1f) r1 -= r10
  3: (85) call pc+1 // r1=fp0 ?
  4: (95) exit

This commit changes bpf_global_subprog_stack_access_bytes() to handle
ARG_SCALAR and ARG_PTR_TO_DYNPTR, thus addressing the full set of
possible returned values.

Fixes: 8212c1c2986d ("bpf: Derive global subprog stack liveness from BTF signatures")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 kernel/bpf/verifier.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 2f190abe3448..e477ef4465d5 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -14871,7 +14871,7 @@ bpf_global_subprog_stack_access_bytes(struct bpf_verifier_env *env, struct bpf_i
 
 	switch (base_type(sub->args[arg].arg_type)) {
 	case ARG_UNUSED:	/* Not an argument slot. */
-	case ARG_ANYTHING:	/* A scalar, the callee can't dereference it. */
+	case ARG_SCALAR:	/* A scalar, the callee can't dereference it. */
 		return (struct arg_access_info) {};
 	case ARG_PTR_TO_BTF_ID:
 		/*
@@ -14887,6 +14887,10 @@ bpf_global_subprog_stack_access_bytes(struct bpf_verifier_env *env, struct bpf_i
 			info.must_write = true;
 		}
 		return info;
+	case ARG_PTR_TO_DYNPTR:
+		/* The callee may adjust the view, but cannot reinitialize the dynptr. */
+		info.size = BPF_DYNPTR_SIZE;
+		return info;
 	default:
 		return info;
 	}

-- 
2.53.0

[PATCH bpf-next v2 2/7] bpf: avoid duplicate declaration for BPF_SCEV_REGS_NUM

[Eduard Zingerman]

The "bpf: Use SCEV to widen bounded loops" commit introduced a
second (identical and unnecessary) definition for the
BPF_SCEV_REGS_NUM macro.

Fixes: 088a5477a9bd ("bpf: Avoid widening registers that hinder exact stack-slot tracking")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 include/linux/bpf_verifier.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 54cb6d3d0653..791398e14962 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -708,9 +708,6 @@ struct bpf_loop_exit {
 	int to; /* instruction outside the loop */
 };
 
-/* SCEV/widening register space: r0..r10 plus every stack slot of a frame. */
-#define BPF_SCEV_REGS_NUM (MAX_BPF_REG + MAX_BPF_STACK_SLOTS)
-
 struct bpf_loop {
 	struct bpf_backedge backedges[MAX_BACKEDGES];
 	/* edges exiting from this loop, includes edges from nested loops */

-- 
2.53.0

[PATCH bpf-next v2 3/7] bpf: reg_bounds_sync() comment fixup

[Eduard Zingerman]

Array traversal logic in btf_struct_access() starts from reg_smin().
Update comment to match the logic.

Fixes: 0892ef2a7ef3 ("bpf: Representation for intervals with steps")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 kernel/bpf/verifier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e477ef4465d5..ec136cf377c1 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2354,7 +2354,7 @@ static void reg_bounds_sync(struct bpf_reg_state *reg)
 	 * potentially w/o intersection, or intersecting after N
 	 * tnum_step()'s, where N can be large. On the other hand,
 	 * step+base *must* be in sync with r64 in order for
-	 * array traversal logic starting at reg_umin() to be sound.
+	 * array traversal logic starting at reg_smin() to be sound.
 	 * Hence, place this as a final step in the reg_bounds_sync().
 	 */
 	__update_bounds_from_step(reg);

-- 
2.53.0

[PATCH bpf-next v2 4/7] selftests/bpf: stack effects of scalar/dynptr global subprog params

[Eduard Zingerman]

Verify that a frame pointer derived value does not induce stack
liveness effects, when passed as a scalar argument of a
global function.

Verify that a stack-based dynptr passed to a global function marks
live only corresponding 16 bytes.

Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 .../selftests/bpf/progs/verifier_live_stack.c      | 56 ++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_live_stack.c b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
index 3d88cb28b8fe..d2fdc65c84c5 100644
--- a/tools/testing/selftests/bpf/progs/verifier_live_stack.c
+++ b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
@@ -182,6 +182,62 @@ __naked void global_callee_arg(void)
 	::: __clobber_all);
 }
 
+__noinline int global_int_arg(int x)
+{
+	return 0;
+}
+
+SEC("socket")
+__success __log_level(2)
+__msg("stack use/def subprog#0 global_noop_int_arg (d0,cs0):")
+__msg_next("  0: (bf) r1 = r10{{$}}")
+__msg_next("  1: (07) r1 += -8{{$}}")
+__msg_next("  2: (1f) r1 -= r10{{$}}")
+__msg_next("  3: (85) call pc+1{{$}}")
+__msg_next("  4: (95) exit")
+__naked void global_noop_int_arg(void)
+{
+	asm volatile (
+	"r1 = r10;"
+	"r1 += -8;"
+	"r1 -= r10;"		/* This is a scalar now. */
+	"call global_int_arg;"	/* And should not be tracked as stack effect. */
+	"exit;"
+	::: __clobber_all);
+}
+
+static char global_dynptr_buf[8];
+
+__noinline int global_noop_dynptr_arg(struct bpf_dynptr *p)
+{
+	return 0;
+}
+
+SEC("socket")
+__success __log_level(2)
+/* A global dynptr argument may read/write only its 16 bytes, with no definite write. */
+__msg("stack use/def subprog#0 global_callee_dynptr_arg (d0,cs0):")
+__msg("  7: (bf) r1 = r10{{$}}")
+__msg_next("  8: (07) r1 += -32{{$}}")
+__msg_next("  9: (85) call pc+1{{ +}}; use: fp0-24 fp0-32 may_def: fp0-24 fp0-32{{$}}")
+__msg_next(" 10: (95) exit{{$}}")
+__naked void global_callee_dynptr_arg(void)
+{
+	asm volatile (
+	"r1 = %[global_dynptr_buf] ll;"
+	"r2 = 8;"
+	"r3 = 0;"
+	"r4 = r10;"
+	"r4 += -32;"
+	"call %[bpf_dynptr_from_mem];"
+	"r1 = r10;"
+	"r1 += -32;"
+	"call global_noop_dynptr_arg;"
+	"exit;"
+	:: __imm_addr(global_dynptr_buf), __imm(bpf_dynptr_from_mem)
+	: __clobber_all);
+}
+
 struct task_struct { int pid; };
 
 __noinline int global_noop_btf_arg(struct task_struct *p __arg_untrusted)

-- 
2.53.0

[PATCH bpf-next v2 5/7] selftests/bpf: harden __msg pattern for global_callee_btf_arg

[Eduard Zingerman]

The original pattern:

  __msg("3: (85) call pc+{{[0-9]+}}\n")

Is ambigous, as this line is printed on the main verification pass as
well. Harden the test case by ensuring a __msg_next sequence matching
the stack use/def results specifically.

Fixes: 063c85f5d8c7 ("selftests/bpf: Tests for BTF-based global subprog stack liveness")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 tools/testing/selftests/bpf/progs/verifier_live_stack.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/progs/verifier_live_stack.c b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
index d2fdc65c84c5..5f9b11a81260 100644
--- a/tools/testing/selftests/bpf/progs/verifier_live_stack.c
+++ b/tools/testing/selftests/bpf/progs/verifier_live_stack.c
@@ -249,7 +249,11 @@ SEC("socket")
 __success __log_level(2)
 /* Untrusted BTF pointer arguments need no caller stack state. */
 __msg("stack use/def subprog#0 global_callee_btf_arg (d0,cs0):")
-__msg("3: (85) call pc+{{[0-9]+}}\n")
+__msg_next("  0: (7a) *(u64 *)(r10 -8) = 0{{.*}}")
+__msg_next("  1: (bf) r1 = r10{{$}}")
+__msg_next("  2: (07) r1 += -8{{$}}")
+__msg_next("  3: (85) call pc+1{{$}}")
+__msg_next("  4: (95) exit{{$}}")
 __naked void global_callee_btf_arg(void)
 {
 	asm volatile (

-- 
2.53.0

[PATCH bpf-next v2 6/7] selftests/bpf: harden __msg patterns for step_movsx_bounds_on_line

[Eduard Zingerman]

The `{{.*}}` in the pattern for R5 below might hide the `step=...`
logging from the __no_step annotation. Replace it with full expected
log instead. Also drop __no_step for R3 above, where it is
unnecessary.

Fixes: 2db5837f9ada ("selftests/bpf: Tests for register base/step arithmetic")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 tools/testing/selftests/bpf/progs/verifier_bounds_step.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds_step.c b/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
index c9ee1c7efcbb..d824a5d48a39 100644
--- a/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
+++ b/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
@@ -338,9 +338,9 @@ SEC("socket")
 __success __log_level(2)
 __msg("r1 = (s16)r0 {{.*}}R1=scalar(id={{[0-9]+}},smin=smin32=0,smax=umax=smax32=umax32=168,{{.*}}step=0+24)")
 __msg("r2 = (s16)r0 {{.*}}R2=scalar(smin=smin32=-24,smax=smax32=144,{{.*}}step=0+24)")
-__msg("r3 = (s8)r0 {{.*}}R3=scalar(smin=smin32=-128,smax=smax32=127)") __no_step
+__msg("r3 = (s8)r0 {{.*}}R3=scalar(smin=smin32=-128,smax=smax32=127)")
 __msg("w4 = (s16)w1 {{.*}}R4=scalar(id={{[0-9]+}},smin=smin32=0,smax=umax=smax32=umax32=168,{{.*}}step=0+24)")
-__msg("w5 = (s8)w1 {{.*}}R5=scalar({{.*}}smin32=-128,smax32=127,{{.*}})") __no_step
+__msg("w5 = (s8)w1 {{.*}}R5=scalar({{.*}}smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))")
 __naked void step_movsx_bounds_on_line(void)
 {
 	asm volatile ("					\

-- 
2.53.0

[PATCH bpf-next v2 7/7] selftests/bpf: BPF_F_ANY_ALIGNMENT for byte_array_size_spanning()

[Eduard Zingerman]

The test case indexes inside `char bytes[32]` array with unaligned
offset. Use BPF_F_ANY_ALIGNMENT flag to avoid the test rejection for
unrelated reason.

Fixes: e187fac8ac6b ("selftests/bpf: Tests for varying offset access to PTR_TO_BTF_ID")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 tools/testing/selftests/bpf/progs/verifier_btf_array_access.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_btf_array_access.c b/tools/testing/selftests/bpf/progs/verifier_btf_array_access.c
index be001cc77f81..9dc2c9a5f8b7 100644
--- a/tools/testing/selftests/bpf/progs/verifier_btf_array_access.c
+++ b/tools/testing/selftests/bpf/progs/verifier_btf_array_access.c
@@ -114,6 +114,7 @@ int long_array_in_bounds(void *ctx)
  */
 SEC("syscall")
 __failure
+__flag(BPF_F_ANY_ALIGNMENT)
 __msg("invalid variable offset access into struct outer")
 int byte_array_size_spanning(void *ctx)
 {

-- 
2.53.0

Re: [PATCH bpf-next v2 6/7] selftests/bpf: harden __msg patterns for step_movsx_bounds_on_line

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] bpf/selftests: missing closing parenthesis in regex pattern allows test to pass incorrectly
--

commit 0cba693bc29a347d1c334a9ea3f7803ac49d1bab
Author: Eduard Zingerman <eddyz87@gmail.com>

selftests/bpf: harden __msg patterns for step_movsx_bounds_on_line

The commit drops the __no_step annotations and replaces them with full
expected logs to prevent {{.*}} from matching and hiding step=... logging.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds_step.c b/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
> index c9ee1c7efcbb8..d824a5d48a394 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_bounds_step.c
> @@ -338,9 +338,9 @@ SEC("socket")
>  __success __log_level(2)
>  __msg("r1 = (s16)r0 {{.*}}R1=scalar(id={{[0-9]+}},smin=smin32=0,smax=umax=smax32=umax32=168,{{.*}}step=0+24)")
>  __msg("r2 = (s16)r0 {{.*}}R2=scalar(smin=smin32=-24,smax=smax32=144,{{.*}}step=0+24)")
> -__msg("r3 = (s8)r0 {{.*}}R3=scalar(smin=smin32=-128,smax=smax32=127)") __no_step
> +__msg("r3 = (s8)r0 {{.*}}R3=scalar(smin=smin32=-128,smax=smax32=127)")

[Severity: Low]
Is this string literal missing a closing parenthesis after 127?

Since the explicit __no_step check was removed, and the test_loader uses
unanchored regex matching for patterns containing {{.*}}, matching as a
prefix allows the test to silently succeed even if the verifier incorrectly
appends step=... to the log.

Should the pattern be 127)) to strictly match the end of the scalar state
and preserve the intended test coverage?

>  __msg("w4 = (s16)w1 {{.*}}R4=scalar(id={{[0-9]+}},smin=smin32=0,smax=umax=smax32=umax32=168,{{.*}}step=0+24)")
> -__msg("w5 = (s8)w1 {{.*}}R5=scalar({{.*}}smin32=-128,smax32=127,{{.*}})") __no_step
> +__msg("w5 = (s8)w1 {{.*}}R5=scalar({{.*}}smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))")
>  __naked void step_movsx_bounds_on_line(void)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-scev-minimal-v3-followups-v2-0-6d9d61965486@gmail.com?part=6