From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org, 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: Fri, 05 Jan 2024 01:29:08 +0200 [thread overview]
Message-ID: <67a4b5b8bdb24a80c1289711c7c156b6c8247403.camel@gmail.com> (raw)
In-Reply-To: <CAEf4Bzb0LdSPnFZ-kPRftofA6LsaOkxXLN4_fr9BLR3iG-te-g@mail.gmail.com>
On Thu, 2024-01-04 at 15:09 -0800, Andrii Nakryiko wrote:
[...]
> > 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.
>
>
> hm... does that test have to do so many things and do all these u64 vs
> u32 vs u8 conversions?
The test is actually quite minimal, the longest part is conjuring of
varying offset pointer in r2, here it is with additional comments:
/* Write 0 or 100500 to fp-16, 0 is on the first verification pass */
"call %[bpf_get_prandom_u32];"
"r9 = 100500;"
"if r0 > 42 goto +1;"
"r9 = 0;"
"*(u64 *)(r10 - 16) = r9;"
/* prepare a variable length access */
"call %[bpf_get_prandom_u32];"
"r0 &= 0xf;" /* r0 range is [0; 15] */
"r1 = -1;"
"r1 -= r0;" /* r1 range is [-16; -1] */
"r2 = r10;"
"r2 += r1;" /* r2 range is [fp-16; fp-1] */
/* do a variable length write of constant 0 */
"r0 = 0;"
"*(u8 *)(r2 + 0) = r0;"
/* use fp-16 to access an array of length 2 */
"r1 = %[two_byte_buf];"
"r2 = *(u32 *)(r10 -16);"
"r1 += r2;"
"*(u8 *)(r1 + 0) = r2;" /* this should not be fine */
"exit;"
> Can we try a simple test were we spill u64
> SCALAR (imprecise) zero register to fp-8 or fp-16, and then use those
> fp-8|fp-16 slot as an index into an array in precise context. Then
> have a separate delayed branch that will write non-zero to fp-8|fp-16.
> States shouldn't converge and this should be rejected.
That is what test above does but it also includes varying offset access.
[...]
next prev parent reply other threads:[~2024-01-04 23:29 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
2024-01-04 23:09 ` Andrii Nakryiko
2024-01-04 23:29 ` Eduard Zingerman [this message]
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=67a4b5b8bdb24a80c1289711c7c156b6c8247403.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii.nakryiko@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