netdev - Re: [RFC PATCH bpf-next 0/2] bpf: Implement shared persistent fast(er) 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 23 Aug 2021 17:38:47 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     hjm2133@...umbia.edu
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org, sdf@...gle.com,
        ppenkov@...gle.com
Subject: Re: [RFC PATCH bpf-next 0/2] bpf: Implement shared persistent
 fast(er) sk_storoage mode

On Mon, Aug 23, 2021 at 05:52:50PM -0400, Hans Montero wrote:
> From: Hans Montero <hjm2133@...umbia.edu>
> 
> This patch set adds a BPF local storage optimization. The first patch adds the
> feature, and the second patch extends the bpf selftests so that the feature is
> tested.
> 
> We are running BPF programs for each egress packet and noticed that
> bpf_sk_storage_get incurs a significant amount of cpu time. By inlining the
> storage into struct sock and accessing that instead of performing a map lookup,
> we expect to reduce overhead for our specific use-case. 

Looks like a hack to me. Please share the perf numbers and setup details.
I think there should be a different way to address performance concerns
without going into such hacks.

> This also has a
> side-effect of persisting the socket storage, which can be beneficial.

Without explicit opt-in such sharing will cause multiple bpf progs to corrupt
each other data.