On Fri, 2023-12-08 at 17:09 -0800, Andrii Nakryiko wrote:
> When verifier validates BPF_ST_MEM instruction that stores known
> constant to stack (e.g., *(u64 *)(r10 - 8) = 123), it effectively spills
> a fake register with a constant (but initially imprecise) value to
> a stack slot. Because read-side logic treats it as a proper register
> fill from stack slot, we need to mark such stack slot initialization as
> INSN_F_STACK_ACCESS instruction to stop precision backtracking from
> missing it.
>
> Fixes: 41f6f64e6999 ("bpf: support non-r10 register spill/fill to/from stack in precision tracking")
> Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
> ---
> kernel/bpf/verifier.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index fb690539d5f6..727a59e4a647 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -4498,7 +4498,6 @@ static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
> __mark_reg_known(&fake_reg, insn->imm);
> fake_reg.type = SCALAR_VALUE;
> save_register_state(env, state, spi, &fake_reg, size);
> - insn_flags = 0; /* not a register spill */
> } else if (reg && is_spillable_regtype(reg->type)) {
> /* register containing pointer is being spilled into stack */
> if (size != BPF_REG_SIZE) {
So, the problem is that for some 'r5 = r10; *(u64 *)(r5 - 8) = 123'
backtracking won't reset precision mark for -8, right?
That's not a tragedy we just get more precision marks than needed,
however, I think that same logic applies to the MISC/ZERO case below.
I'll look through the tests in the morning.
