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: <20180219204120.GJ15918@orbyte.nwl.cc>
Date:   Mon, 19 Feb 2018 21:41:20 +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 01:41:29PM -0500, David Miller wrote:
> From: Phil Sutter <phil@....cc>
> Date: Mon, 19 Feb 2018 19:05:51 +0100
> 
> > 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.
> 
> I did not say nftables adjusted performance one way or another.  It kept
> it on the same order of magnitude.  And this is a design decision.

Oh, seems I missed your point then. What subject did you have in mind
when you wrote "emphasis on flexibility often at the expense of
performance"? I thought you were talking about nftables.

> > 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've always stated that low power, low end, systems are just a good
> place for high performance filtering as high end ones.

Do you think these systems are likely to receive a NIC (or some sort of
co-processor) which allows for offloading eBPF to? Maybe I miss the
point again, but this is the only argument for bpfilter over nftables -
and that only if one ignores the option to implement an eBPF backend for
nftables VM). OK, maybe this clarifies once I know what you had in mind
when you wrote that reply.

Cheers, Phil