netdev - [bpf-next PATCH 0/4] Sockmap Updates

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-next>] [day] [month] [year] [list]

Message-ID: <20180401145728.24727.706.stgit@john-Precision-Tower-5810>
Date:   Sun, 01 Apr 2018 08:00:49 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     ast@...nel.org, daniel@...earbox.net
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: [bpf-next PATCH 0/4] Sockmap Updates

Some additions for sockmap. First a couple fixes from the last round
to ensure (a) we account for corked memory when a socket is closing
and (b) do not set a null sk_prot value when tcp_close and sockmap
destroy race.

Then the new addition is a hash map type. As the sockmap use cases
become more complex and the number of socks involved becomes larger
mapping and tracking the socks in the array complicates the control
plane quite a bit. By adding a hash mode we are able to simplify this.

A couple design decisions were made here. First I did not try to
embed this in the existing hashtab logic. If we had done this
we lose the ability to build custom htab and element data structures.
This ended up complicating both hashtab and sockmap. This was the
same rational for making both sockmap and devmap distinct objects
outside of the standard array map. The slight downside of this
decision is some code becomes duplicated. The biggest offender is
get_next_key, which is close to a cut'n'paste.  However, this
seems better than forcing sockmap.c to follow hashtab data
structures limiting our opportunities for optimizations.

The second decision was to use a new set of helper routines that
are distinct to the new SOCKHASH map type. Because the original
sockmap API (sk_* helpers) used a u32 (and is already in UAPI) it
could not be changed to a 'void *key' type needed for SOCKHASH. The
msg hooks are not in a released UAPI but we use sk_* helpers and
msg_* helpers together in our programs and creating an API with
different patterns depending on context seemed undesireable. So
this series adds two sets of helpers one for SOCKMAP and one for
SOCKHASH. The nice fallout of this is the verifier knows these
signatures and is happy to throw errors when users use the wrong
types.

For testing I changed the sample sockmap program to use SOCKHASH
maps and verified everything passed as expected with a couple
different key sizes.

The test patches will be added after sockmap sample is converted
into selftests. This work is currently in-progress because the
selftests API needs to be extended to support multiple programs
in as single file with different types.

---

John Fastabend (4):
      bpf: sockmap, free memory on sock close with cork data
      bpf: sockmap, duplicates release calls may NULL sk_prot
      bpf: sockmap, refactor sockmap routines to work with hashmap
      bpf: sockmap, add hash map support

 include/linux/bpf.h                       |    8 
 include/linux/bpf_types.h                 |    1 
 include/linux/filter.h                    |    3 
 include/net/tcp.h                         |    3 
 include/uapi/linux/bpf.h                  |    6 
 kernel/bpf/core.c                         |    1 
 kernel/bpf/sockmap.c                      |  667 ++++++++++++++++++++++++++---
 kernel/bpf/verifier.c                     |   14 +
 net/core/filter.c                         |   81 +++-
 tools/bpf/bpftool/map.c                   |    1 
 tools/include/uapi/linux/bpf.h            |    6 
 tools/testing/selftests/bpf/bpf_helpers.h |   13 -
 12 files changed, 700 insertions(+), 104 deletions(-)

--
Signature