From: Eduard Zingerman <eddyz87@gmail.com>
To: Yonghong Song <yonghong.song@linux.dev>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Martin KaFai Lau <kafai@fb.com>
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Track aligned st store as imprecise spilled registers
Date: Thu, 04 Jan 2024 23:10:58 +0200 [thread overview]
Message-ID: <69410e766d68f4e69400ba9b1c3b4c56feaa2ca2.camel@gmail.com> (raw)
In-Reply-To: <cbff1224-39c0-4555-a688-53e921065b97@linux.dev>
On Thu, 2024-01-04 at 12:12 -0800, Yonghong Song wrote:
[...]
> > > @@ -4613,11 +4613,28 @@ static int check_stack_write_var_off(struct bpf_verifier_env *env,
> > >
> > > /* Variable offset writes destroy any spilled pointers in range. */
> > > for (i = min_off; i < max_off; i++) {
> > > + struct bpf_reg_state *spill_reg;
> > > u8 new_type, *stype;
> > > - int slot, spi;
> > > + int slot, spi, j;
> > >
> > > slot = -i - 1;
> > > spi = slot / BPF_REG_SIZE;
> > > +
> > > + /* If writing_zero and the the spi slot contains a spill of value 0,
> > > + * maintain the spill type.
> > > + */
> > > + if (writing_zero && !(i % BPF_REG_SIZE) && is_spilled_scalar_reg(&state->stack[spi])) {
> > Talked to Andrii today, and he noted that spilled reg should be marked
> > precise at this point.
>
> Could you help explain why?
>
> Looks we did not mark reg as precise with fixed offset as below:
>
> if (reg && !(off % BPF_REG_SIZE) && register_is_bounded(reg) && env->bpf_capable) {
> save_register_state(env, state, spi, reg, size);
> /* Break the relation on a narrowing spill. */
> if (fls64(reg->umax_value) > BITS_PER_BYTE * size)
> state->stack[spi].spilled_ptr.id = 0;
> } else if (!reg && !(off % BPF_REG_SIZE) && is_bpf_st_mem(insn) &&
> insn->imm != 0 && env->bpf_capable) {
>
> I probably missed something about precision tracking...
The discussed justification was that if verifier assumes something
about the value of scalar (in this case that it is 0) such scalar
should be marked precise (e.g. this is done for value_regno in
check_stack_write_var_off()).
This seemed logical at the time of discussion, however, I can't figure
a counter example at the moment. It appears that whatever are
assumptions in check_stack_write_var_off() if spill is used in the
precise context it would be marked eventually.
E.g. the following is correctly rejected:
SEC("raw_tp")
__log_level(2) __flag(BPF_F_TEST_STATE_FREQ)
__failure
__naked void var_stack_1(void)
{
asm volatile (
"call %[bpf_get_prandom_u32];"
"r9 = 100500;"
"if r0 > 42 goto +1;"
"r9 = 0;"
"*(u64 *)(r10 - 16) = r9;"
"call %[bpf_get_prandom_u32];"
"r0 &= 0xf;"
"r1 = -1;"
"r1 -= r0;"
"r2 = r10;"
"r2 += r1;"
"r0 = 0;"
"*(u8 *)(r2 + 0) = r0;"
"r1 = %[two_byte_buf];"
"r2 = *(u32 *)(r10 -16);"
"r1 += r2;"
"*(u8 *)(r1 + 0) = r2;" /* this should not be fine */
"exit;"
:
: __imm_ptr(two_byte_buf),
__imm(bpf_get_prandom_u32)
: __clobber_common);
}
So now I'm not sure :(
Sorry for too much noise.
next prev parent reply other threads:[~2024-01-04 21:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 23:26 [PATCH bpf-next v2 1/2] bpf: Track aligned st store as imprecise spilled registers Yonghong Song
2024-01-03 23:26 ` [PATCH bpf-next v2 2/2] selftests/bpf: Add a selftest with not-8-byte aligned BPF_ST Yonghong Song
2024-01-04 16:37 ` [PATCH bpf-next v2 1/2] bpf: Track aligned st store as imprecise spilled registers Eduard Zingerman
2024-01-04 17:13 ` Yonghong Song
2024-01-04 18:43 ` Eduard Zingerman
2024-01-04 18:30 ` Eduard Zingerman
2024-01-04 20:12 ` Yonghong Song
2024-01-04 21:10 ` Eduard Zingerman [this message]
2024-01-04 23:09 ` Andrii Nakryiko
2024-01-04 23:29 ` Eduard Zingerman
2024-01-05 1:05 ` Andrii Nakryiko
2024-01-05 7:14 ` Yonghong Song
2024-01-05 8:10 ` Yonghong Song
2024-01-05 23:37 ` Eduard Zingerman
2024-01-08 18:59 ` Yonghong Song
2024-01-08 19:06 ` Eduard Zingerman
2024-01-08 19:40 ` Yonghong Song
2024-01-05 23:52 ` Eduard Zingerman
2024-01-08 19:51 ` Yonghong Song
2024-01-08 20:05 ` Eduard Zingerman
2024-01-08 21:51 ` Yonghong Song
2024-01-08 23:18 ` Andrii Nakryiko
2024-01-04 23:03 ` Andrii Nakryiko
2024-01-05 0:49 ` Andrii Nakryiko
2024-01-08 23:23 ` Andrii Nakryiko
2024-01-08 23:39 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69410e766d68f4e69400ba9b1c3b4c56feaa2ca2.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=kernel-team@fb.com \
--cc=kuniyu@amazon.com \
--cc=martin.lau@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox