netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH net-next 0/7] eBPF support for cls_bpf
@ 2015-02-11  0:15 Daniel Borkmann
  2015-02-11  0:15 ` [PATCH net-next 1/7] ebpf: remove kernel test stubs Daniel Borkmann
                   ` (6 more replies)
  0 siblings, 7 replies; 15+ messages in thread
From: Daniel Borkmann @ 2015-02-11  0:15 UTC (permalink / raw)
  To: jiri; +Cc: ast, netdev, Daniel Borkmann

I'm sending this out only as RFC as the merge window is open
anyway and Dave's pull request pending.

My plan would be to get this work fully refined and remove
some rough edges until net-next opens up again, submitting
it as non-RFC.

So for the time being similarly as the recent OVS eBPF action
patchset this may serve as a discussion ground, also wrt to
the BPF tutorial at netdev01 [1].

I presume on top of this e.g. Jiri might want to follow-up
with act_bpf, I'm also open/happy to contribute to it.

The series starts with a couple of cleanups and making the
prog type infrastructure pluggable in eBPF. Most interesting
is probably the last patch that adds actual support and the
iproute2 bits from the link below.

With regards to accessing fields from the context (here: skb),
I leave that for future work just as we currently do in socket
filters, also with regard to the currently ongoing ABI discussion
from tracing side. Nevertheless, the state with these patches
still allows for interesting functionality to be implemented as
complex classifiers, e.g. such as a fully fledged C-like flow
dissector as shown in bpf samples directory and the like.

iproute2 part:

   http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf

I have configured and built LLVM with: --enable-experimental-targets=BPF

  [1] https://www.netdev01.org/sessions/15

Thanks !

Daniel Borkmann (7):
  ebpf: remove kernel test stubs
  ebpf: constify various function pointer structs
  ebpf: check first for MAXINSNS in bpf_prog_load
  ebpf: extend program type/subsystem registration
  ebpf: export BPF_PSEUDO_MAP_FD to uapi
  ebpf: remove CONFIG_BPF_SYSCALL ifdefs in socket filter code
  cls_bpf: add initial eBPF support for programmable classifiers

 include/linux/bpf.h          |  46 +++++++---
 include/linux/filter.h       |   2 -
 include/uapi/linux/bpf.h     |   3 +
 include/uapi/linux/pkt_cls.h |   1 +
 kernel/bpf/Makefile          |   3 -
 kernel/bpf/arraymap.c        |   6 +-
 kernel/bpf/hashtab.c         |   6 +-
 kernel/bpf/helpers.c         |   9 +-
 kernel/bpf/syscall.c         |  96 +++++++++++++++------
 kernel/bpf/test_stub.c       |  78 -----------------
 kernel/bpf/verifier.c        |  28 ++++--
 net/core/filter.c            | 169 +++++++++++++++++-------------------
 net/sched/cls_bpf.c          | 200 ++++++++++++++++++++++++++++++++-----------
 samples/bpf/libbpf.h         |   4 +-
 samples/bpf/test_verifier.c  |   5 +-
 15 files changed, 374 insertions(+), 282 deletions(-)
 delete mode 100644 kernel/bpf/test_stub.c

-- 
1.9.3

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [PATCH net-next 4/7] ebpf: extend program type/subsystem registration
@ 2015-02-11  1:37 Alexei Starovoitov
  2015-02-12 21:06 ` Daniel Borkmann
  0 siblings, 1 reply; 15+ messages in thread
From: Alexei Starovoitov @ 2015-02-11  1:37 UTC (permalink / raw)
  To: Daniel Borkmann, Thomas Graf
  Cc: Jiří Pírko, Network Development

On Tue, Feb 10, 2015 at 4:15 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> When various subsystems/modules start to make use of ebpf
> e.g. cls_bpf, act_bpf, ovs, ... we need to make sure, they
> can register their program types only once.
>
> Moreover, we also need to serialize various registrations,
> currently program type registration is being done without
> locks. (We should make sure to not race in future when we
> allow registration from modules.)
>
> Last but not least, we need to be able to register subsystems
> from module context as it's not sufficient to have them only
> as built-in at all time.

imo that is scary. there is no unregister_type by design,
since I didn't want modules to use bpf.
My concern that if we allow modules to register new program
types we allow bypass of gpl and all safety checks we've
put in place.
Modules will define whatever helper functions they like.
We won't be able to control or even code review this stuff.
I think all types and all helper functions should be built-in.
This way we know what bpf is used for and that it's not abused.
Yes, having all types and helpers built-in creates
some challenges for ovs and tc, but I think it's much
safer long term.
I think for networking one or two prog types will be enough
and hopefully ovs/tc/... will settle on common set of helpers.

'bpf for modules' was one of the topics I wanted to
discuss at netdev01. Looks like we started it early...

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2015-02-12 21:06 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-11  0:15 [RFC PATCH net-next 0/7] eBPF support for cls_bpf Daniel Borkmann
2015-02-11  0:15 ` [PATCH net-next 1/7] ebpf: remove kernel test stubs Daniel Borkmann
2015-02-11  0:42   ` Alexei Starovoitov
2015-02-11  0:15 ` [PATCH net-next 2/7] ebpf: constify various function pointer structs Daniel Borkmann
2015-02-11  0:43   ` Alexei Starovoitov
2015-02-11  0:15 ` [PATCH net-next 3/7] ebpf: check first for MAXINSNS in bpf_prog_load Daniel Borkmann
2015-02-11  1:21   ` Alexei Starovoitov
2015-02-12 20:43     ` Daniel Borkmann
2015-02-11  0:15 ` [PATCH net-next 4/7] ebpf: extend program type/subsystem registration Daniel Borkmann
2015-02-11  0:15 ` [PATCH net-next 5/7] ebpf: export BPF_PSEUDO_MAP_FD to uapi Daniel Borkmann
2015-02-11  1:39   ` Alexei Starovoitov
2015-02-11  0:15 ` [PATCH net-next 6/7] ebpf: remove CONFIG_BPF_SYSCALL ifdefs in socket filter code Daniel Borkmann
2015-02-11  0:15 ` [PATCH net-next 7/7] cls_bpf: add initial eBPF support for programmable classifiers Daniel Borkmann
2015-02-11  1:37 [PATCH net-next 4/7] ebpf: extend program type/subsystem registration Alexei Starovoitov
2015-02-12 21:06 ` Daniel Borkmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).