netdev - Re: [PATCH bpf 2/2] bpf: selftest to verify mixing bpf2bpf calls and tailcalls with insn patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Jun 2021 18:21:08 +0200
From:   Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     ast@...nel.org, daniel@...earbox.net, andriin@...com,
        netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH bpf 2/2] bpf: selftest to verify mixing bpf2bpf calls and
 tailcalls with insn patch

On Wed, Jun 09, 2021 at 09:26:01AM -0700, John Fastabend wrote:
> Maciej Fijalkowski wrote:
> > On Tue, Jun 08, 2021 at 12:30:33PM -0700, John Fastabend wrote:
> > > This adds some extra noise to the tailcall_bpf2bpf4 tests that will cause
> > > verifier to patch insns. This then moves around subprog start/end insn
> > > index and poke descriptor insn index to ensure that verify and JIT will
> > > continue to track these correctly.
> > 
> > This test is the most complicated one where I tried to document the scope
> > of it on the side of prog_tests/tailcalls.c. I feel that it would make it
> > more difficult to debug it if under any circumstances something would have
> > been broken with that logic.
> > 
> > Maybe a separate test scenario? Or is this an overkill? If so, I would
> > vote for moving it to tailcall_bpf2bpf1.c and have a little comment that
> > testing other bpf helpers mixed in is in scope of that test.
> 
> I like pushing it into the complex test to get the most instruction
> patching combinations possible.

Makes sense after a second thought, that was the intention of that test
case, to squeeze out the feature out here.

I still would ask to have it commented on the prog_tests/tailcalls.c side,
WDYT?

> 
> > 
> > > 
> > > Reviewed-by: Daniel Borkmann <daniel@...earbox.net>
> > > Signed-off-by: John Fastabend <john.fastabend@...il.com>
> > > ---
> > >  .../selftests/bpf/progs/tailcall_bpf2bpf4.c        |   17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c
> > > index 9a1b166b7fbe..0d70de5f97e2 100644
> > > --- a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c
> > > +++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c
> > > @@ -2,6 +2,13 @@
> > >  #include <linux/bpf.h>
> > >  #include <bpf/bpf_helpers.h>
> > >  
> > > +struct {
> > > +	__uint(type, BPF_MAP_TYPE_ARRAY);
> > > +	__uint(max_entries, 1);
> > > +	__uint(key_size, sizeof(__u32));
> > > +	__uint(value_size, sizeof(__u32));
> > > +} nop_table SEC(".maps");
> > > +
> > >  struct {
> > >  	__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
> > >  	__uint(max_entries, 3);
> > > @@ -11,9 +18,19 @@ struct {
> > >  
> > >  static volatile int count;
> > >  
> > > +__noinline
> > > +int subprog_noise(struct __sk_buff *skb)
> > > +{
> > > +	__u32 key = 0;
> > > +
> > > +	bpf_map_lookup_elem(&nop_table, &key);
> > > +	return 0;
> > > +}
> > > +
> > >  __noinline
> > >  int subprog_tail_2(struct __sk_buff *skb)
> > >  {
> > > +	subprog_noise(skb);
> > >  	bpf_tail_call_static(skb, &jmp_table, 2);
> > >  	return skb->len * 3;
> > >  }
> > > 
> > > 
> 
>