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  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:   Fri, 21 Aug 2020 12:22:46 +0200
From:   Jakub Sitnicki <>
To:     Alexei Starovoitov <>
Cc:     bpf <>,
        Network Development <>,
        kernel-team <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Andrii Nakryiko <>,
        Lorenz Bauer <>,
        Marek Majkowski <>,
        Martin KaFai Lau <>, Yonghong Song <>
Subject: Re: BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks

On Fri, Aug 21, 2020 at 12:18 AM CEST, Alexei Starovoitov wrote:
> On Thu, Aug 20, 2020 at 3:29 AM Jakub Sitnicki <> wrote:
>> On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote:


>> > Long term we should probably stop doing *_kern style of ctx passing
>> > into bpf progs.
>> > We have BTF, CO-RE and freplace now. This old style of memset *_kern and manual
>> > ctx conversion has performance implications and annoying copy-paste of ctx
>> > conversion routines.
>> > For this particular case instead of introducing udp4_lookup_run_bpf()
>> > and copying registers into stack we could have used freplace of
>> > udp4_lib_lookup2.
>> > More verifier work needed, of course.
>> > My main point that existing approach "lets prep args for bpf prog to
>> > run" that is used
>> > pretty much in every bpf hook is no longer necessary.
>> Andrii has also suggested leveraging BTF [0], but to expose the *_kern
>> struct directly to BPF prog instead of emitting ctx access instructions.
>> What I'm curious about is if we get rid of prepping args and ctx
>> conversion, then how do we limit what memory BPF prog can access?
>> Say, I'm passing a struct sock * to my BPF prog. If it's not a tracing
>> prog, then I don't want it to have access to everything that is
>> reachable from struct sock *. This is where this approach currently
>> breaks down for me.
> Why do you want to limit it?
> Time after time we keep extending structs in uapi/bpf.h because new
> use cases are coming up. Just let the prog access everything.

I guess I wasn't thinking big enough :-)

Powered by blists - more mailing lists