BPF List
 help / color / mirror / Atom feed
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
> > 


  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