Subject: Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal <[email-masked]>
Date: Wed, 21 Feb 2018 13:13:03 +0100

Pablo Neira Ayuso <[email-masked]> wrote:
> On Tue, Feb 20, 2018 at 05:52:54PM -0800, Alexei Starovoitov wrote:
> > On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote:
> > > 
> > >   Don't get me wrong, no software is safe from security issues, but if you
> > >   don't abstract your resources in the right way, you have more chance to
> > >   have experimence more problems.
> > 
> > interesting point.
> > The key part of iptables and nft design is heavy use of indirect calls.
> > The execution of single iptable rule is ~3 indirect calls.
> > Quite a lot worse in nft where every expression is an indirect call.
> 
> That's right. Netfilter is probably too modular, probably we can
> revisit this to find a better balance, actually Felix Fietkau was
> recently rising concerns on this, specifically in environments with
> limited space to store the kernel image. We'll have a look, thanks for
> remind us about this.

Agree, we have too many config knobs, probably a good idea to turn some
modules into plain .o (like cmp and bitwise).

Obvious candidates are: meta, numgen, limit, objref, quota, reject.

We should probably also consider removing
CONFIG_NFT_SET_RBTREE and CONFIG_NFT_SET_HASH and just always
build both too (at least rbtree since that offers interval).

For the indirect call issue we can use direct calls from eval loop for
some of the more frequently used ones, similar to what we do already
for nft_cmp_fast_expr.  But maybe we don't even have to if we can
get help to build a jitter that takes an nftables netlink table dump
and builds jit code from that.