From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, kernel-team@fb.com, yhs@fb.com,
memxor@gmail.com, ecree.xilinx@gmail.com
Subject: Re: [PATCH bpf-next 4/7] selftests/bpf: verify states_equal() maintains idmap across all frames
Date: Wed, 14 Dec 2022 18:38:15 +0200 [thread overview]
Message-ID: <943ce05e135fae9450d2b6e0c59f50f11bf022b2.camel@gmail.com> (raw)
In-Reply-To: <CAEf4BzZ7VEdYb+qSFLnY2jkvUHEfNHtzK7WYWMKezyRcjkV=Zg@mail.gmail.com>
On Tue, 2022-12-13 at 16:35 -0800, Andrii Nakryiko wrote:
> On Fri, Dec 9, 2022 at 5:58 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> >
> > A test case that would erroneously pass verification if
> > verifier.c:states_equal() maintains separate register ID mappings for
> > call frames.
> >
> > Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> > ---
>
> It's so hard to read these tests. Moving forward, let's try adding new
> verifier tests like this using __naked functions and embedded
> assembly. With recent test loader changes ([0]), there isn't much
> that's needed, except for a few simple examples to get us started and
> perhaps __flags(BPF_F_TEST_STATE_FREQ) support. The upside is that
> using maps or global variables from assembly is now possible and easy,
> and doesn't require any custom loader support at all.
>
>
> [0] https://patchwork.kernel.org/project/netdevbpf/list/?series=702713&state=*
>
>
This is very nice, I'll try to use it for the next patch-set.
How do you think it should look like for test_verifier kind of tests?
The easiest way would be to just add new BPF sources under progs/
and have some prog_tests/verifier.c like this:
int test_verifier()
...
RUN_TESTS(array_access),
RUN_TESTS(scalar_ids)
...
Thus reusing the build mechanics for skeletons etc.
However, it seems to break current logical separation
between "unit" tests in test_verifier and "functional"
tests in test_progs. But this may be ok.
> > tools/testing/selftests/bpf/verifier/calls.c | 82 ++++++++++++++++++++
> > 1 file changed, 82 insertions(+)
> >
> > diff --git a/tools/testing/selftests/bpf/verifier/calls.c b/tools/testing/selftests/bpf/verifier/calls.c
> > index 3193915c5ee6..bcd15b26dcee 100644
> > --- a/tools/testing/selftests/bpf/verifier/calls.c
> > +++ b/tools/testing/selftests/bpf/verifier/calls.c
> > @@ -2305,3 +2305,85 @@
> > .errstr = "!read_ok",
> > .result = REJECT,
> > },
> > +/* Make sure that verifier.c:states_equal() considers IDs from all
> > + * frames when building 'idmap' for check_ids().
> > + */
> > +{
> > + "calls: check_ids() across call boundary",
> > + .insns = {
> > + /* Function main() */
> > + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> > + /* fp[-24] = map_lookup_elem(...) ; get a MAP_VALUE_PTR_OR_NULL with some ID */
> > + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> > + BPF_LD_MAP_FD(BPF_REG_1,
> > + 0),
> > + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> > + BPF_STX_MEM(BPF_DW, BPF_REG_FP, BPF_REG_0, -24),
> > + /* fp[-32] = map_lookup_elem(...) ; get a MAP_VALUE_PTR_OR_NULL with some ID */
> > + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> > + BPF_LD_MAP_FD(BPF_REG_1,
> > + 0),
> > + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> > + BPF_STX_MEM(BPF_DW, BPF_REG_FP, BPF_REG_0, -32),
> > + /* call foo(&fp[-24], &fp[-32]) ; both arguments have IDs in the current
> > + * ; stack frame
> > + */
> > + BPF_MOV64_REG(BPF_REG_1, BPF_REG_FP),
> > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -24),
> > + BPF_MOV64_REG(BPF_REG_2, BPF_REG_FP),
> > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -32),
> > + BPF_CALL_REL(2),
> > + /* exit 0 */
> > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > + BPF_EXIT_INSN(),
> > + /* Function foo()
> > + *
> > + * r9 = &frame[0].fp[-24] ; save arguments in the callee saved registers,
> > + * r8 = &frame[0].fp[-32] ; arguments are pointers to pointers to map value
> > + */
> > + BPF_MOV64_REG(BPF_REG_9, BPF_REG_1),
> > + BPF_MOV64_REG(BPF_REG_8, BPF_REG_2),
> > + /* r7 = ktime_get_ns() */
> > + BPF_EMIT_CALL(BPF_FUNC_ktime_get_ns),
> > + BPF_MOV64_REG(BPF_REG_7, BPF_REG_0),
> > + /* r6 = ktime_get_ns() */
> > + BPF_EMIT_CALL(BPF_FUNC_ktime_get_ns),
> > + BPF_MOV64_REG(BPF_REG_6, BPF_REG_0),
> > + /* if r6 > r7 goto +1 ; no new information about the state is derived from
> > + * ; this check, thus produced verifier states differ
> > + * ; only in 'insn_idx'
> > + * r9 = r8
> > + */
> > + BPF_JMP_REG(BPF_JGT, BPF_REG_6, BPF_REG_7, 1),
> > + BPF_MOV64_REG(BPF_REG_9, BPF_REG_8),
> > + /* r9 = *r9 ; verifier get's to this point via two paths:
> > + * ; (I) one including r9 = r8, verified first;
> > + * ; (II) one excluding r9 = r8, verified next.
> > + * ; After load of *r9 to r9 the frame[0].fp[-24].id == r9.id.
> > + * ; Suppose that checkpoint is created here via path (I).
> > + * ; When verifying via (II) the r9.id must be compared against
> > + * ; frame[0].fp[-24].id, otherwise (I) and (II) would be
> > + * ; incorrectly deemed equivalent.
> > + * if r9 == 0 goto <exit>
> > + */
> > + BPF_LDX_MEM(BPF_DW, BPF_REG_9, BPF_REG_9, 0),
> > + BPF_JMP_IMM(BPF_JEQ, BPF_REG_9, 0, 1),
> > + /* r8 = *r8 ; read map value via r8, this is not safe
> > + * r0 = *r8 ; because r8 might be not equal to r9.
> > + */
> > + BPF_LDX_MEM(BPF_DW, BPF_REG_8, BPF_REG_8, 0),
> > + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_8, 0),
> > + /* exit 0 */
> > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > + BPF_EXIT_INSN(),
> > + },
> > + .flags = BPF_F_TEST_STATE_FREQ,
> > + .fixup_map_hash_8b = { 3, 9 },
> > + .result = REJECT,
> > + .errstr = "R8 invalid mem access 'map_value_or_null'",
> > + .result_unpriv = REJECT,
> > + .errstr_unpriv = "",
> > + .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
> > +},
> > --
> > 2.34.1
> >
next prev parent reply other threads:[~2022-12-14 16:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 13:57 [PATCH bpf-next 0/7] stricter register ID checking in regsafe() Eduard Zingerman
2022-12-09 13:57 ` [PATCH bpf-next 1/7] bpf: regsafe() must not skip check_ids() Eduard Zingerman
2022-12-14 0:35 ` Andrii Nakryiko
2022-12-14 13:25 ` Eduard Zingerman
2022-12-14 19:37 ` Andrii Nakryiko
2022-12-09 13:57 ` [PATCH bpf-next 2/7] selftests/bpf: test cases for regsafe() bug skipping check_id() Eduard Zingerman
2022-12-09 13:57 ` [PATCH bpf-next 3/7] bpf: states_equal() must build idmap for all function frames Eduard Zingerman
2022-12-14 0:35 ` Andrii Nakryiko
2022-12-14 15:33 ` Eduard Zingerman
2022-12-14 17:24 ` Andrii Nakryiko
2022-12-09 13:57 ` [PATCH bpf-next 4/7] selftests/bpf: verify states_equal() maintains idmap across all frames Eduard Zingerman
2022-12-14 0:35 ` Andrii Nakryiko
2022-12-14 16:38 ` Eduard Zingerman [this message]
2022-12-14 17:10 ` Andrii Nakryiko
2022-12-09 13:57 ` [PATCH bpf-next 5/7] bpf: use check_ids() for active_lock comparison Eduard Zingerman
2022-12-09 13:57 ` [PATCH bpf-next 6/7] selftests/bpf: Add pruning test case for bpf_spin_lock Eduard Zingerman
2022-12-10 21:45 ` Alexei Starovoitov
2022-12-09 13:57 ` [PATCH bpf-next 7/7] selftests/bpf: test case for relaxed prunning of active_lock.id Eduard Zingerman
2022-12-10 21:50 ` [PATCH bpf-next 0/7] stricter register ID checking in regsafe() patchwork-bot+netdevbpf
2022-12-14 0:34 ` Andrii Nakryiko
2022-12-14 16:28 ` Eduard Zingerman
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=943ce05e135fae9450d2b6e0c59f50f11bf022b2.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=ecree.xilinx@gmail.com \
--cc=kernel-team@fb.com \
--cc=memxor@gmail.com \
--cc=yhs@fb.com \
/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