Immediate is incorrectly cast to u32 before being spilled, losing sign
information. The range information is incorrect after load again. Fix
immediate spill by remove the cast. The second patch add a test case
for this.
Signed-off-by: Hao Sun <[email protected]>
---
Changes in v2:
- Add fix and cc tags.
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Hao Sun (2):
bpf: Fix check_stack_write_fixed_off() to correctly spill imm
selftests/bpf: Add test for immediate spilled to stack
kernel/bpf/verifier.c | 2 +-
tools/testing/selftests/bpf/verifier/bpf_st_mem.c | 32 +++++++++++++++++++++++
2 files changed, 33 insertions(+), 1 deletion(-)
---
base-commit: f1c73396133cb3d913e2075298005644ee8dfade
change-id: 20231026-fix-check-stack-write-c40996694dfa
Best regards,
--
Hao Sun <[email protected]>
Add a test to check if the verifier correctly reason about the sign
of an immediate spilled to stack by BPF_ST instruction.
Signed-off-by: Hao Sun <[email protected]>
---
tools/testing/selftests/bpf/verifier/bpf_st_mem.c | 32 +++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
index 3af2501082b2..0ba23807c46c 100644
--- a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
+++ b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
@@ -65,3 +65,35 @@
.expected_attach_type = BPF_SK_LOOKUP,
.runs = -1,
},
+{
+ "BPF_ST_MEM stack imm sign",
+ /* Check if verifier correctly reasons about sign of an
+ * immediate spilled to stack by BPF_ST instruction.
+ *
+ * fp[-8] = -44;
+ * r0 = fp[-8];
+ * if r0 s< 0 goto ret0;
+ * r0 = -1;
+ * exit;
+ * ret0:
+ * r0 = 0;
+ * exit;
+ */
+ .insns = {
+ BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, -44),
+ BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8),
+ BPF_JMP_IMM(BPF_JSLT, BPF_REG_0, 0, 2),
+ BPF_MOV64_IMM(BPF_REG_0, -1),
+ BPF_EXIT_INSN(),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ /* Use prog type that requires return value in range [0, 1] */
+ .prog_type = BPF_PROG_TYPE_SK_LOOKUP,
+ .expected_attach_type = BPF_SK_LOOKUP,
+ .result = VERBOSE_ACCEPT,
+ .runs = -1,
+ .errstr = "0: (7a) *(u64 *)(r10 -8) = -44 ; R10=fp0 fp-8_w=-44\
+ 2: (c5) if r0 s< 0x0 goto pc+2\
+ 2: R0_w=-44",
+},
--
2.34.1
On Wed, 2023-11-01 at 08:33 +0100, Hao Sun wrote:
> Add a test to check if the verifier correctly reason about the sign
> of an immediate spilled to stack by BPF_ST instruction.
>
> Signed-off-by: Hao Sun <[email protected]>
> ---
> tools/testing/selftests/bpf/verifier/bpf_st_mem.c | 32 +++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> index 3af2501082b2..0ba23807c46c 100644
> --- a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> +++ b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> @@ -65,3 +65,35 @@
> .expected_attach_type = BPF_SK_LOOKUP,
> .runs = -1,
> },
> +{
> + "BPF_ST_MEM stack imm sign",
> + /* Check if verifier correctly reasons about sign of an
> + * immediate spilled to stack by BPF_ST instruction.
> + *
> + * fp[-8] = -44;
> + * r0 = fp[-8];
> + * if r0 s< 0 goto ret0;
> + * r0 = -1;
> + * exit;
> + * ret0:
> + * r0 = 0;
> + * exit;
> + */
> + .insns = {
> + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, -44),
> + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8),
> + BPF_JMP_IMM(BPF_JSLT, BPF_REG_0, 0, 2),
> + BPF_MOV64_IMM(BPF_REG_0, -1),
> + BPF_EXIT_INSN(),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + },
> + /* Use prog type that requires return value in range [0, 1] */
> + .prog_type = BPF_PROG_TYPE_SK_LOOKUP,
> + .expected_attach_type = BPF_SK_LOOKUP,
> + .result = VERBOSE_ACCEPT,
> + .runs = -1,
> + .errstr = "0: (7a) *(u64 *)(r10 -8) = -44 ; R10=fp0 fp-8_w=-44\
> + 2: (c5) if r0 s< 0x0 goto pc+2\
> + 2: R0_w=-44",
> +},
>
Please note that this test case fails on CI [0], full log below:
2023-11-01T07:49:51.2841702Z #116/p BPF_ST_MEM stack imm sign FAIL
2023-11-01T07:49:51.2843456Z Unexpected verifier log!
2023-11-01T07:49:51.2844968Z EXP: 2: R0_w=-44
2023-11-01T07:49:51.2845583Z RES:
2023-11-01T07:49:51.2846693Z func#0 @0
2023-11-01T07:49:51.2848932Z 0: R1=ctx(off=0,imm=0) R10=fp0
2023-11-01T07:49:51.2853045Z 0: (7a) *(u64 *)(r10 -8) = -44 ; R10=fp0 fp-8_w=-44
2023-11-01T07:49:51.2857391Z 1: (79) r0 = *(u64 *)(r10 -8) ; R0_w=-44 R10=fp0 fp-8_w=-44
2023-11-01T07:49:51.2859127Z 2: (c5) if r0 s< 0x0 goto pc+2
2023-11-01T07:49:51.2862943Z mark_precise: frame0: last_idx 2 first_idx 0 subseq_idx -1
2023-11-01T07:49:51.2867511Z mark_precise: frame0: regs=r0 stack= before 1: (79) r0 = *(u64 *)(r10 -8)
2023-11-01T07:49:51.2872217Z mark_precise: frame0: regs= stack=-8 before 0: (7a) *(u64 *)(r10 -8) = -44
2023-11-01T07:49:51.2872816Z 5: R0_w=-44
2023-11-01T07:49:51.2875653Z 5: (b7) r0 = 0 ; R0_w=0
2023-11-01T07:49:51.2876493Z 6: (95) exit
I suspect that after recent logging fixes instruction number printed
after jump changed and that's why test case no longer passes.
Note: you can check CI status for submitted patch-sets using link [1].
[0] https://github.com/kernel-patches/bpf/actions/runs/6717053909/job/18254330860
[1] https://patchwork.kernel.org/project/netdevbpf/list/
On Wed, Nov 1, 2023 at 12:05 PM Eduard Zingerman <[email protected]> wrote:
>
> On Wed, 2023-11-01 at 08:33 +0100, Hao Sun wrote:
> > Add a test to check if the verifier correctly reason about the sign
> > of an immediate spilled to stack by BPF_ST instruction.
> >
> > Signed-off-by: Hao Sun <[email protected]>
> > ---
> > tools/testing/selftests/bpf/verifier/bpf_st_mem.c | 32 +++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> > index 3af2501082b2..0ba23807c46c 100644
> > --- a/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> > +++ b/tools/testing/selftests/bpf/verifier/bpf_st_mem.c
> > @@ -65,3 +65,35 @@
> > .expected_attach_type = BPF_SK_LOOKUP,
> > .runs = -1,
> > },
> > +{
> > + "BPF_ST_MEM stack imm sign",
> > + /* Check if verifier correctly reasons about sign of an
> > + * immediate spilled to stack by BPF_ST instruction.
> > + *
> > + * fp[-8] = -44;
> > + * r0 = fp[-8];
> > + * if r0 s< 0 goto ret0;
> > + * r0 = -1;
> > + * exit;
> > + * ret0:
> > + * r0 = 0;
> > + * exit;
> > + */
> > + .insns = {
> > + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, -44),
> > + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8),
> > + BPF_JMP_IMM(BPF_JSLT, BPF_REG_0, 0, 2),
> > + BPF_MOV64_IMM(BPF_REG_0, -1),
> > + BPF_EXIT_INSN(),
> > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > + BPF_EXIT_INSN(),
> > + },
> > + /* Use prog type that requires return value in range [0, 1] */
> > + .prog_type = BPF_PROG_TYPE_SK_LOOKUP,
> > + .expected_attach_type = BPF_SK_LOOKUP,
> > + .result = VERBOSE_ACCEPT,
> > + .runs = -1,
> > + .errstr = "0: (7a) *(u64 *)(r10 -8) = -44 ; R10=fp0 fp-8_w=-44\
> > + 2: (c5) if r0 s< 0x0 goto pc+2\
> > + 2: R0_w=-44",
> > +},
> >
>
> Please note that this test case fails on CI [0], full log below:
>
> 2023-11-01T07:49:51.2841702Z #116/p BPF_ST_MEM stack imm sign FAIL
> 2023-11-01T07:49:51.2843456Z Unexpected verifier log!
> 2023-11-01T07:49:51.2844968Z EXP: 2: R0_w=-44
> 2023-11-01T07:49:51.2845583Z RES:
> 2023-11-01T07:49:51.2846693Z func#0 @0
> 2023-11-01T07:49:51.2848932Z 0: R1=ctx(off=0,imm=0) R10=fp0
> 2023-11-01T07:49:51.2853045Z 0: (7a) *(u64 *)(r10 -8) = -44 ; R10=fp0 fp-8_w=-44
> 2023-11-01T07:49:51.2857391Z 1: (79) r0 = *(u64 *)(r10 -8) ; R0_w=-44 R10=fp0 fp-8_w=-44
> 2023-11-01T07:49:51.2859127Z 2: (c5) if r0 s< 0x0 goto pc+2
> 2023-11-01T07:49:51.2862943Z mark_precise: frame0: last_idx 2 first_idx 0 subseq_idx -1
> 2023-11-01T07:49:51.2867511Z mark_precise: frame0: regs=r0 stack= before 1: (79) r0 = *(u64 *)(r10 -8)
> 2023-11-01T07:49:51.2872217Z mark_precise: frame0: regs= stack=-8 before 0: (7a) *(u64 *)(r10 -8) = -44
> 2023-11-01T07:49:51.2872816Z 5: R0_w=-44
> 2023-11-01T07:49:51.2875653Z 5: (b7) r0 = 0 ; R0_w=0
> 2023-11-01T07:49:51.2876493Z 6: (95) exit
>
> I suspect that after recent logging fixes instruction number printed
> after jump changed and that's why test case no longer passes.
>
Yes, so I guess we can just drop the line number there, will send patch v3.
> Note: you can check CI status for submitted patch-sets using link [1].
>
> [0] https://github.com/kernel-patches/bpf/actions/runs/6717053909/job/18254330860
> [1] https://patchwork.kernel.org/project/netdevbpf/list/
Thanks.