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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180219180551.GH15918@orbyte.nwl.cc>
Date:   Mon, 19 Feb 2018 19:05:51 +0100
From:   Phil Sutter <phil@....cc>
To:     David Miller <davem@...emloft.net>
Cc:     laforge@...monks.org, fw@...len.de, daniel@...earbox.net,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

Hi David,

On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
> From: Phil Sutter <phil@....cc>
> Date: Mon, 19 Feb 2018 18:14:11 +0100
> 
> > OK, so reading between the lines you're saying that nftables project
> > has failed to provide an adequate successor to iptables?
> 
> Whilst it is great that the atomic table update problem was solved, I
> think the emphasis on flexibility often at the expense of performance
> was a bad move.

I don't see a lack of performance in nftables when being compared to
iptables (as we have now). From my point of view, it's quite the
contrary: nftables did a great job in picking up iptables performance
afterthoughts (e.g. ipset) and leveraging that to the max(TM) (verdict
maps, concatenated set entries). Assuming the virtual machine design
principle isn't just marketing but sets the course for JIT ruleset
optimizations, there's some margin as well.

So from my perspective, one should say nftables increased flexibility
without sacrificing performance.

> Netfilter's chronic performance differential is why a lot of mindshare
> was lost to userspace networking technologies.
> 
> Thankfully, we are gaining back a lot of that userbase with XDP and
> eBPF, thanks to the hard work of many individuals.
> 
> To think that people are going to be willing to take the performance
> hit (whatever it's size) to go back to the "more flexible" nftables
> is really not a realistic expectation.
> 
> And we have amassed enough interest and momentum that offloading eBPF
> in hardware on current and future hardware is happening.
> 
> So I am going to direct us in directions that allow those realities to
> be taken advantage of, rather than pretending that this transition
> hasn't occurred already.

Hey, you secretly changed the topic! ;)

Yes, even with my limited experience I noticed that there is quite some
demand for even faster packet processing in Linux, mostly for rather
custom scenarios like forwarding into containers/VMs. Though my point
was about general purpose firewalling abilities in Linux, say people
securing their desktop or maintaining networks with less demands on
performance. I guess it will be a while until consumer hardware comes
with smart NICs (or they become affordable), so for those people
nftables is definitely a step forward.

Cheers, Phil