From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.us.es ([193.147.175.20]:38772 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbeBUMBo (ORCPT ); Wed, 21 Feb 2018 07:01:44 -0500 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id F337E114FCE for ; Wed, 21 Feb 2018 13:01:41 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id C72A3DA249 for ; Wed, 21 Feb 2018 13:01:41 +0100 (CET) Date: Wed, 21 Feb 2018 13:01:23 +0100 From: Pablo Neira Ayuso To: Alexei Starovoitov Cc: David Miller , phil@nwl.cc, laforge@gnumonks.org, fw@strlen.de, daniel@iogearbox.net, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org Subject: Re: [PATCH RFC 0/4] net: add bpfilter Message-ID: <20180221120123.7ze57exniznjjavs@salvia> References: <20180219153808.GI5490@nataraja> <20180219.104459.157566294655687535.davem@davemloft.net> <20180219171411.GG15918@orbyte.nwl.cc> <20180219.122226.896334578399862770.davem@davemloft.net> <20180220104431.xsrfvdaqbw6uxmwt@salvia> <20180221015251.7ejj3br76rwumfyi@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180221015251.7ejj3br76rwumfyi@ast-mbp.dhcp.thefacebook.com> Sender: netdev-owner@vger.kernel.org List-ID: 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. [...] > CPUs will eventually be fixed and IBRS_ALL will become reality. > Until then the kernel has to deal with the performance issues. Hopefully, so we can all skip these problems. Thanks.