From: Florian Westphal <fw@xxxxxxxxx> Date: Tue, 13 Mar 2018 14:41:39 +0100 > David Miller <davem@xxxxxxxxxxxxx> wrote: >> From: Felix Fietkau <nbd@xxxxxxxx> >> Date: Mon, 12 Mar 2018 20:30:01 +0100 >> >> > It's not dead and useless. In its current state, it has a software fast >> > path that significantly improves nftables routing/NAT throughput, >> > especially on embedded devices. >> > On some devices, I've seen "only" 20% throughput improvement (along with >> > CPU usage reduction), on others it's quite a bit lot more. This is >> > without any extra drivers or patches aside from what's posted. >> >> I wonder if this software fast path has the exploitability problems that >> things like the ipv4 routing cache and the per-cpu flow cache both had. > > No, entries in the flow table are backed by an entry in the conntrack > table, and that has an upper ceiling. > > As decision of when an entry gets placed into the flow table is > configureable via ruleset (nftables, iptables will be coming too), one > can tie the 'fastpathing' to almost-arbitrary criterion, e.g. > > 'only flows from trusted internal network' > 'only flows that saw two-way communication' > 'only flows that sent more than 100kbyte' > > or any combination thereof. > > Do you see another problem that needs to be addressed? Ok, that seems to constrain the exposure. We should talk at some point about how exposed conntrack itself is. -- 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
