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: <20180219211309.GF23857@breakpoint.cc>
Date:   Mon, 19 Feb 2018 22:13:09 +0100
From:   Florian Westphal <fw@...len.de>
To:     David Miller <davem@...emloft.net>
Cc:     phil@....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

David Miller <davem@...emloft.net> 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.

Thats not true, IMO.

One idea previosuly discussed was to add a 'freeze' option
to our nftables syntax.  Essentially what would happen is that further
updates to the table become impossible, with exception of named sets
(which can be changed independently similar to ebpf maps is suppose).

As further updates to the table are then no longer allowed this would
then make it possible to e.g. jit all rules into a single program.

The table could still be removed (and recreated) of course so its
not impossible to make changes, but no longer at the rule level.

> Netfilter's chronic performance differential is why a lot of mindshare
> was lost to userspace networking technologies.

I think this is a unfair statement and also not true.
If you refer to the linear-ruleset-evaluation of iptables, this is
what ipset was added for.

Yes, its a band aid.  But again, that problem come from the UAPI
format/limitations of only having one source or destination address per
rule, a limitation not present in nftables.

Other reason why iptables is a bit more costly than needed (although it
IS rather fast given, no spinlocks in main eval loop) are the rule
counter updates which were built into the design all those years ago.

Again, a problem solved in nftables by making the counters optional.

If you want to speedup forward path with XDP -- fine.
But AFAIU its still possible with XDP to have packets being sent to
full stack, right?

If so, it would be possible to even combine nftables with XDP, f.e.
by allowing an ebpf program running on host CPU to query netfilter
conntrack.

No Entry -> push to normal path
Entry -> check 'fastpath' flag (which would be in nf_conn struct).
Not set -> also normal path.
Otherwise continue XDP, stack bypass.

nftables would have a rule similar to this:
nft add rule inet forward ct state established ct label set fastpath
to switch such conntrack to xdp mode.

This decision can then be combined with nftables infra,
for example 'fatpath for tcp flows that saw more than 1mbit of data
in either direction' or the like.

Yes, this needs ebpf support for conntrack and NAT transformations,
and it does beg question how to handle the details, e.g. conntrack
timeouts.  Don't see any unsolveable issues with this though.

Also has similarities with the 'flow offload' proposal, i.e. we
could perhaps even reuse what we already have to add provide flow
offload in software using epbf/XDP as offload backend.