All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitrii Banshchikov <me@ubique.spb.ru>
To: bpf@vger.kernel.org
Cc: Dmitrii Banshchikov <me@ubique.spb.ru>,
	ast@kernel.org, davem@davemloft.net, daniel@iogearbox.net,
	andrii@kernel.org, kafai@fb.com, songliubraving@fb.com,
	yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org,
	netdev@vger.kernel.org, rdna@fb.com
Subject: [PATCH bpf-next v1 00/10] bpfilter
Date: Thu,  3 Jun 2021 14:14:15 +0400	[thread overview]
Message-ID: <20210603101425.560384-1-me@ubique.spb.ru> (raw)

The patchset is based on the patches from David S. Miller [1] and
Daniel Borkmann [2].

The main goal of the patchset is to prepare bpfilter for
iptables' configuration blob parsing and code generation.

The patchset introduces data structures and code for matches,
targets, rules and tables.

The current version misses handling of counters. Postpone its
implementation until the code generation phase as it's not clear
yet how to better handle them.

Beside that there is no support of net namespaces at all.

In the next iteration basic code generation shall be introduced.

The rough plan for the code generation.

It seems reasonable to assume that the first rules should cover
most of the packet flow.  This is why they are critical from the
performance point of view.  At the same time number of user
defined rules might be pretty large. Also there is a limit on
size and complexity of a BPF program introduced by the verifier.

There are two approaches how to handle iptables' rules in
generated BPF programs.

The first approach is to generate a BPF program that is an
equivalent to a set of rules on a rule by rule basis. This
approach should give the best performance. The drawback is the
limitation from the verifier on size and complexity of BPF
program.

The second approach is to use an internal representation of rules
stored in a BPF map and use bpf_for_each_map_elem() helper to
iterate over them. In this case the helper's callback is a BPF
function that is able to process any valid rule.

Combination of the two approaches should give most of the
benefits - a heuristic should help to select a small subset of
the rules for code generation on a rule by rule basis. All other
rules are cold and it should be possible to store them in an
internal form in a BPF map. The rules will be handled by
bpf_for_each_map_elem().  This should remove the limit on the
number of supported rules.

During development it was useful to use statically linked
sanitizers in bpfilter usermode helper. Also it is possible to
use fuzzers but it's not clear if it is worth adding them to the
test infrastructure - because there are no other fuzzers under
tools/testing/selftests currently.

Patch 1 adds definitions of the used types.
Patch 2 adds logging to bpfilter.
Patch 3 adds bpfilter header to tools
Patch 4 adds an associative map.
Patches 5/6/7/8 add code for matches, targets, rules and table.
Patch 9 handles hooked setsockopt(2) calls.
Patch 10 uses prepared code in main().

Here is an example:
% dmesg  | tail -n 2
[   23.636102] bpfilter: Loaded bpfilter_umh pid 181
[   23.658529] bpfilter: started
% /usr/sbin/iptables-legacy -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
% /usr/sbin/iptables-legacy -A INPUT -p udp --dport 23 -j DROP
% /usr/sbin/iptables-legacy -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:23

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
% /usr/sbin/iptables-legacy -F
% /usr/sbin/iptables-legacy -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
%

v0 -> v1
IO:
  * Use ssize_t in pvm_read, pvm_write for total_bytes
  * Move IO functions into sockopt.c and main.c
Logging:
  * Use LOGLEVEL_EMERG, LOGLEVEL_NOTICE, LOGLEVE_DEBUG
    while logging to /dev/kmsg
  * Prepend log message with <n> where n is log level
  * Conditionally enable BFLOG_DEBUG messages
  * Merge bflog.{h,c} into context.h
Matches:
  * Reorder fields in struct match_ops for tight packing
  * Get rid of struct match_ops_map
  * Rename udp_match_ops to xt_udp
  * Use XT_ALIGN macro
  * Store payload size in match size
  * Move udp match routines into a separate file
Targets:
  * Reorder fields in struct target_ops for tight packing
  * Get rid of struct target_ops_map
  * Add comments for convert_verdict function
Rules:
  * Add validation
Tables:
  * Combine table_map and table_list into table_index
  * Add validation
Sockopts:
  * Handle IPT_SO_GET_REVISION_TARGET

1. https://lore.kernel.org/patchwork/patch/902785/
2. https://lore.kernel.org/patchwork/patch/902783/

Dmitrii Banshchikov (10):
  bpfilter: Add types for usermode helper
  bpfilter: Add logging facility
  tools: Add bpfilter usermode helper header
  bpfilter: Add map container
  bpfilter: Add struct match
  bpfilter: Add struct target
  bpfilter: Add struct rule
  bpfilter: Add struct table
  bpfilter: Add handling of setsockopt() calls
  bpfilter: Handle setsockopts

 .clang-format                                 |   2 +-
 include/uapi/linux/bpfilter.h                 | 155 +++++++
 net/bpfilter/Makefile                         |   3 +-
 net/bpfilter/context.c                        | 181 ++++++++
 net/bpfilter/context.h                        |  46 ++
 net/bpfilter/main.c                           | 123 ++++--
 net/bpfilter/map-common.c                     |  64 +++
 net/bpfilter/map-common.h                     |  19 +
 net/bpfilter/match.c                          |  49 +++
 net/bpfilter/match.h                          |  33 ++
 net/bpfilter/rule.c                           | 163 +++++++
 net/bpfilter/rule.h                           |  32 ++
 net/bpfilter/sockopt.c                        | 409 ++++++++++++++++++
 net/bpfilter/sockopt.h                        |  14 +
 net/bpfilter/table.c                          | 339 +++++++++++++++
 net/bpfilter/table.h                          |  39 ++
 net/bpfilter/target.c                         | 118 +++++
 net/bpfilter/target.h                         |  49 +++
 net/bpfilter/xt_udp.c                         |  33 ++
 tools/include/uapi/linux/bpfilter.h           | 179 ++++++++
 .../testing/selftests/bpf/bpfilter/.gitignore |   5 +
 tools/testing/selftests/bpf/bpfilter/Makefile |  30 ++
 .../selftests/bpf/bpfilter/bpfilter_util.h    |  39 ++
 .../testing/selftests/bpf/bpfilter/test_map.c |  63 +++
 .../selftests/bpf/bpfilter/test_match.c       |  63 +++
 .../selftests/bpf/bpfilter/test_rule.c        |  55 +++
 .../selftests/bpf/bpfilter/test_target.c      |  85 ++++
 27 files changed, 2346 insertions(+), 44 deletions(-)
 create mode 100644 net/bpfilter/context.c
 create mode 100644 net/bpfilter/context.h
 create mode 100644 net/bpfilter/map-common.c
 create mode 100644 net/bpfilter/map-common.h
 create mode 100644 net/bpfilter/match.c
 create mode 100644 net/bpfilter/match.h
 create mode 100644 net/bpfilter/rule.c
 create mode 100644 net/bpfilter/rule.h
 create mode 100644 net/bpfilter/sockopt.c
 create mode 100644 net/bpfilter/sockopt.h
 create mode 100644 net/bpfilter/table.c
 create mode 100644 net/bpfilter/table.h
 create mode 100644 net/bpfilter/target.c
 create mode 100644 net/bpfilter/target.h
 create mode 100644 net/bpfilter/xt_udp.c
 create mode 100644 tools/include/uapi/linux/bpfilter.h
 create mode 100644 tools/testing/selftests/bpf/bpfilter/.gitignore
 create mode 100644 tools/testing/selftests/bpf/bpfilter/Makefile
 create mode 100644 tools/testing/selftests/bpf/bpfilter/bpfilter_util.h
 create mode 100644 tools/testing/selftests/bpf/bpfilter/test_map.c
 create mode 100644 tools/testing/selftests/bpf/bpfilter/test_match.c
 create mode 100644 tools/testing/selftests/bpf/bpfilter/test_rule.c
 create mode 100644 tools/testing/selftests/bpf/bpfilter/test_target.c

-- 
2.25.1


             reply	other threads:[~2021-06-03 10:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 10:14 Dmitrii Banshchikov [this message]
2021-06-03 10:14 ` [PATCH bpf-next v1 01/10] bpfilter: Add types for usermode helper Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 02/10] bpfilter: Add logging facility Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 03/10] tools: Add bpfilter usermode helper header Dmitrii Banshchikov
2021-06-08 16:20   ` Yonghong Song
2021-06-09 10:07     ` Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 04/10] bpfilter: Add map container Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 05/10] bpfilter: Add struct match Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 06/10] bpfilter: Add struct target Dmitrii Banshchikov
2021-06-03 16:47   ` Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 07/10] bpfilter: Add struct rule Dmitrii Banshchikov
2021-06-10  0:30   ` Yonghong Song
2021-06-10 13:16     ` Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 08/10] bpfilter: Add struct table Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 09/10] bpfilter: Add handling of setsockopt() calls Dmitrii Banshchikov
2021-06-03 10:14 ` [PATCH bpf-next v1 10/10] bpfilter: Handle setsockopts Dmitrii Banshchikov
2021-06-10  0:50 ` [PATCH bpf-next v1 00/10] bpfilter Yonghong Song
2021-06-10 13:36   ` Dmitrii Banshchikov
2021-06-10 13:58     ` Daniel Borkmann
2021-06-10 14:56     ` Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210603101425.560384-1-me@ubique.spb.ru \
    --to=me@ubique.spb.ru \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.