netdev - Re: call for bpf progs. Re: [PATCHv2 bpf-next 5/5] selftests: bpf: add test for sk

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 27 Mar 2020 09:08:43 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Lorenz Bauer <lmb@...udflare.com>
Cc:     Yonghong Song <yhs@...com>, Joe Stringer <joe@...d.net.nz>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Martin Lau <kafai@...com>
Subject: Re: call for bpf progs. Re: [PATCHv2 bpf-next 5/5] selftests: bpf:
 add test for sk_assign

On Fri, Mar 27, 2020 at 3:03 AM Lorenz Bauer <lmb@...udflare.com> wrote:
> >
> > Thanks for bringing this up.
> > Yonghong, please correct me if I'm wrong.
> > I think you've experimented with tracking spilled constants. The first issue
> > came with spilling of 4 byte constant. The verifier tracks 8 byte slots and
> > lots of places assume that slot granularity. It's not clear yet how to refactor
> > the verifier. Ideas, help are greatly appreciated.
> > The second concern was pruning, but iirc the experiments were inconclusive.
> > selftests/bpf only has old fb progs. Hence, I think, the step zero is for
> > everyone to contribute their bpf programs written in C. If we have both
> > cilium and cloudflare progs as selftests it will help a lot to guide such long
> > lasting verifier decisions.
>
> Ok, I'll try to get something sorted out. We have a TC classifier that
> would be suitable,
> and I've been meaning to get it open sourced. Does the integration into the
> test suite have to involve running packets through it, or is compile
> and load enough?

It would be great if you can add it as part of test_progs and run it
with one or two packets via prog_test_run like all the tests do.
Thanks!