Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
