From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:27
Hi David,
The following patchset contains Netfilter/IPVS updates for your net-next
tree. This batch comes with more input sanitization for xtables to
address bug reports from fuzzers, preparation works to the flowtable
infrastructure and assorted updates. In no particular order, they are:
1) Make sure userspace provides a valid standard target verdict, from
Florian Westphal.
2) Sanitize error target size, also from Florian.
3) Validate that last rule in basechain matches underflow/policy since
userspace assumes this when decoding the ruleset blob that comes
from the kernel, from Florian.
4) Consolidate hook entry checks through xt_check_table_hooks(),
patch from Florian.
5) Cap ruleset allocations at 512 mbytes, 134217728 rules and reject
very large compat offset arrays, so we have a reasonable upper limit
and fuzzers don't exercise the oom-killer. Patches from Florian.
6) Several WARN_ON checks on xtables mutex helper, from Florian.
7) xt_rateest now has a hashtable per net, from Cong Wang.
8) Consolidate counter allocation in xt_counters_alloc(), from Florian.
9) Earlier xt_table_unlock() call in {ip,ip6,arp,eb}tables, patch
from Xin Long.
10) Set FLOW_OFFLOAD_DIR_* to IP_CT_DIR_* definitions, patch from
Felix Fietkau.
11) Consolidate code through flow_offload_fill_dir(), also from Felix.
12) Inline ip6_dst_mtu_forward() just like ip_dst_mtu_maybe_forward()
to remove a dependency with flowtable and ipv6.ko, from Felix.
13) Cache mtu size in flow_offload_tuple object, this is safe for
forwarding as f87c10a8aa1e describes, from Felix.
14) Rename nf_flow_table.c to nf_flow_table_core.o, to simplify too
modular infrastructure, from Felix.
15) Add rt0, rt2 and rt4 IPv6 routing extension support, patch from
Ahmed Abdelsalam.
16) Remove unused parameter in nf_conncount_count(), from Yi-Hung Wei.
17) Support for counting only to nf_conncount infrastructure, patch
from Yi-Hung Wei.
18) Add strict NFT_CT_{SRC_IP,DST_IP,SRC_IP6,DST_IP6} key datatypes
to nft_ct.
19) Use boolean as return value from ipt_ah and from IPVS too, patch
from Gustavo A. R. Silva.
20) Remove useless parameters in nfnl_acct_overquota() and
nf_conntrack_broadcast_help(), from Taehee Yoo.
21) Use ipv6_addr_is_multicast() from xt_cluster, also from Taehee Yoo.
22) Statify nf_tables_obj_lookup_byhandle, patch from Fengguang Wu.
23) Fix typo in xt_limit, from Geert Uytterhoeven.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Thanks!
----------------------------------------------------------------
The following changes since commit ef3f6c256f0b4711a3ef1489797b95820be5ab01:
Merge branch 'mvpp2-jumbo-frames-support' (2018-03-05 12:55:55 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git HEAD
for you to fetch changes up to 90eee0957b655339d659c0b9bba64f5c90b2233b:
netfilter: nft_ct: add NFT_CT_{SRC,DST}_{IP,IP6} (2018-03-11 22:17:57 +0100)
----------------------------------------------------------------
Ahmed Abdelsalam (1):
netfilter: nf_tables: handle rt0 and rt2 properly
Cong Wang (1):
netfilter: make xt_rateest hash table per net
Felix Fietkau (5):
netfilter: nf_flow_table: use IP_CT_DIR_* values for FLOW_OFFLOAD_DIR_*
netfilter: nf_flow_table: clean up flow_offload_alloc
ipv6: make ip6_dst_mtu_forward inline
netfilter: nf_flow_table: cache mtu in struct flow_offload_tuple
netfilter: nf_flow_table: rename nf_flow_table.c to nf_flow_table_core.c
Florian Westphal (12):
netfilter: x_tables: check standard verdicts in core
netfilter: x_tables: check error target size too
netfilter: x_tables: move hook entry checks into core
netfilter: x_tables: enforce unique and ascending entry points
netfilter: x_tables: cap allocations at 512 mbyte
netfilter: x_tables: limit allocation requests for blob rule heads
netfilter: x_tables: add counters allocation wrapper
netfilter: compat: prepare xt_compat_init_offsets to return errors
netfilter: compat: reject huge allocation requests
netfilter: x_tables: make sure compat af mutex is held
netfilter: x_tables: ensure last rule in base chain matches underflow/policy
netfilter: x_tables: fix build with CONFIG_COMPAT=n
Geert Uytterhoeven (1):
netfilter: xt_limit: Spelling s/maxmum/maximum/
Gustavo A. R. Silva (2):
netfilter: ipt_ah: return boolean instead of integer
ipvs: use true and false for boolean values
Pablo Neira Ayuso (1):
netfilter: nft_ct: add NFT_CT_{SRC,DST}_{IP,IP6}
Taehee Yoo (3):
netfilter: nfnetlink_acct: remove useless parameter
netfilter: xt_cluster: get rid of xt_cluster_ipv6_is_multicast
netfilter: nf_conntrack_broadcast: remove useless parameter
Xin Long (1):
netfilter: unlock xt_table earlier in __do_replace
Yi-Hung Wei (2):
netfilter: Refactor nf_conncount
netfilter: conncount: Support count only use case
kbuild test robot (1):
netfilter: nf_tables: nf_tables_obj_lookup_byhandle() can be static
include/linux/netfilter/nfnetlink_acct.h | 3 +-
include/linux/netfilter/x_tables.h | 5 +-
include/net/ip6_route.h | 21 +++
include/net/ipv6.h | 2 -
include/net/netfilter/nf_conntrack_count.h | 1 -
include/net/netfilter/nf_conntrack_helper.h | 3 +-
include/net/netfilter/nf_flow_table.h | 10 +-
include/net/netfilter/xt_rateest.h | 4 +-
include/uapi/linux/netfilter/nf_tables.h | 15 +-
net/bridge/netfilter/ebtables.c | 10 +-
net/ipv4/netfilter/arp_tables.c | 50 +++---
net/ipv4/netfilter/ip_tables.c | 48 +++---
net/ipv4/netfilter/ipt_ah.c | 2 +-
net/ipv4/netfilter/nf_flow_table_ipv4.c | 17 +-
net/ipv6/ip6_output.c | 22 ---
net/ipv6/netfilter/ip6_tables.c | 50 +++---
net/ipv6/netfilter/nf_flow_table_ipv6.c | 17 +-
net/netfilter/Makefile | 2 +
net/netfilter/ipvs/ip_vs_lblc.c | 4 +-
net/netfilter/ipvs/ip_vs_lblcr.c | 4 +-
net/netfilter/nf_conncount.c | 14 +-
net/netfilter/nf_conntrack_broadcast.c | 1 -
net/netfilter/nf_conntrack_netbios_ns.c | 5 +-
net/netfilter/nf_conntrack_snmp.c | 5 +-
.../{nf_flow_table.c => nf_flow_table_core.c} | 97 +++++------
net/netfilter/nf_tables_api.c | 8 +-
net/netfilter/nfnetlink_acct.c | 3 +-
net/netfilter/nft_ct.c | 38 +++++
net/netfilter/nft_exthdr.c | 3 +
net/netfilter/x_tables.c | 187 +++++++++++++++++++--
net/netfilter/xt_RATEEST.c | 91 +++++++---
net/netfilter/xt_cluster.c | 10 +-
net/netfilter/xt_connlimit.c | 4 +-
net/netfilter/xt_limit.c | 2 +-
net/netfilter/xt_nfacct.c | 2 +-
net/netfilter/xt_rateest.c | 10 +-
36 files changed, 500 insertions(+), 270 deletions(-)
rename net/netfilter/{nf_flow_table.c => nf_flow_table_core.c} (79%)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:29
From: Taehee Yoo <ap420073@gmail.com>
If use the ipv6_addr_is_multicast instead of xt_cluster_ipv6_is_multicast,
then we can reduce code size.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_cluster.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:31
From: "Gustavo A. R. Silva" <redacted>
Return statements in functions returning bool should use
true/false instead of 1/0.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <redacted>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_ah.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:32
From: Xin Long <lucien.xin@gmail.com>
Now it's doing cleanup_entry for oldinfo under the xt_table lock,
but it's not really necessary. After the replacement job is done
in xt_replace_table, oldinfo is not used elsewhere any more, and
it can be freed without xt_table lock safely.
The important thing is that rtnl_lock is called in some xt_target
destroy, which means rtnl_lock, a big lock is used in xt_table
lock, a smaller one. It usually could be the reason why a dead
lock may happen.
Besides, all xt_target/match checkentry is called out of xt_table
lock. It's better also to move all cleanup_entry calling out of
xt_table lock, just as do_replace_finish does for ebtables.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/arp_tables.c | 3 ++-
net/ipv4/netfilter/ip_tables.c | 3 ++-
net/ipv6/netfilter/ip6_tables.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
@@ -925,6 +925,8 @@ static int __do_replace(struct net *net, const char *name,(newinfo->number<=oldinfo->initial_entries))module_put(t->me);+xt_table_unlock(t);+get_old_counters(oldinfo,counters);/* Decrease module usage counts and free resource */
@@ -939,7 +941,6 @@ static int __do_replace(struct net *net, const char *name,net_warn_ratelimited("arptables: counters copy to user failed while replacing table\n");}vfree(counters);-xt_table_unlock(t);returnret;put_module:
@@ -1087,6 +1087,8 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,(newinfo->number<=oldinfo->initial_entries))module_put(t->me);+xt_table_unlock(t);+get_old_counters(oldinfo,counters);/* Decrease module usage counts and free resource */
@@ -1100,7 +1102,6 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,net_warn_ratelimited("iptables: counters copy to user failed while replacing table\n");}vfree(counters);-xt_table_unlock(t);returnret;put_module:
@@ -1105,6 +1105,8 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,(newinfo->number<=oldinfo->initial_entries))module_put(t->me);+xt_table_unlock(t);+get_old_counters(oldinfo,counters);/* Decrease module usage counts and free resource */
@@ -1118,7 +1120,6 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,net_warn_ratelimited("ip6tables: counters copy to user failed while replacing table\n");}vfree(counters);-xt_table_unlock(t);returnret;put_module:
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:33
From: Florian Westphal <fw@strlen.de>
Userspace must provide a valid verdict to the standard target.
The verdict can be either a jump (signed int > 0), or a return code.
Allowed return codes are either RETURN (pop from stack), NF_ACCEPT, DROP
and QUEUE (latter is allowed for legacy reasons).
Jump offsets (verdict > 0) are checked in more detail later on when
loop-detection is performed.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/arp_tables.c | 5 -----
net/ipv4/netfilter/ip_tables.c | 5 -----
net/ipv6/netfilter/ip6_tables.c | 5 -----
net/netfilter/x_tables.c | 49 ++++++++++++++++++++++++++++++++++++-----
4 files changed, 43 insertions(+), 21 deletions(-)
@@ -334,11 +334,6 @@ static int mark_source_chains(const struct xt_table_info *newinfo,t->verdict<0)||visited){unsignedintoldpos,size;-if((strcmp(t->target.u.user.name,-XT_STANDARD_TARGET)==0)&&-t->verdict<-NF_MAX_VERDICT-1)-return0;-/* Return: backtrack through the last*bigjump.*/
@@ -675,9 +700,15 @@ int xt_compat_check_entry_offsets(const void *base, const char *elems,if(target_offset+t->u.target_size>next_offset)return-EINVAL;-if(strcmp(t->u.user.name,XT_STANDARD_TARGET)==0&&-COMPAT_XT_ALIGN(target_offset+sizeof(structcompat_xt_standard_target))!=next_offset)-return-EINVAL;+if(strcmp(t->u.user.name,XT_STANDARD_TARGET)==0){+conststructcompat_xt_standard_target*st=(constvoid*)t;++if(COMPAT_XT_ALIGN(target_offset+sizeof(*st))!=next_offset)+return-EINVAL;++if(!verdict_ok(st->verdict))+return-EINVAL;+}/* compat_xt_entry match has less strict alignment requirements,*otherwisetheyareidentical.Incaseofpaddingdifferences
@@ -757,9 +788,15 @@ int xt_check_entry_offsets(const void *base,if(target_offset+t->u.target_size>next_offset)return-EINVAL;-if(strcmp(t->u.user.name,XT_STANDARD_TARGET)==0&&-XT_ALIGN(target_offset+sizeof(structxt_standard_target))!=next_offset)-return-EINVAL;+if(strcmp(t->u.user.name,XT_STANDARD_TARGET)==0){+conststructxt_standard_target*st=(constvoid*)t;++if(XT_ALIGN(target_offset+sizeof(*st))!=next_offset)+return-EINVAL;++if(!verdict_ok(st->verdict))+return-EINVAL;+}returnxt_check_entry_match(elems,base+target_offset,__alignof__(structxt_entry_match));
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:33
From: Florian Westphal <fw@strlen.de>
Check that userspace ERROR target (custom user-defined chains) match
expected format, and the chain name is null terminated.
This is irrelevant for kernel, but iptables itself relies on sane input
when it dumps rules from kernel.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
@@ -708,6 +719,12 @@ int xt_compat_check_entry_offsets(const void *base, const char *elems,if(!verdict_ok(st->verdict))return-EINVAL;+}elseif(strcmp(t->u.user.name,XT_ERROR_TARGET)==0){+conststructcompat_xt_error_target*et=(constvoid*)t;++if(!error_tg_ok(t->u.target_size,sizeof(*et),+et->errorname,sizeof(et->errorname)))+return-EINVAL;}/* compat_xt_entry match has less strict alignment requirements,
@@ -796,6 +813,12 @@ int xt_check_entry_offsets(const void *base,if(!verdict_ok(st->verdict))return-EINVAL;+}elseif(strcmp(t->u.user.name,XT_ERROR_TARGET)==0){+conststructxt_error_target*et=(constvoid*)t;++if(!error_tg_ok(t->u.target_size,sizeof(*et),+et->errorname,sizeof(et->errorname)))+return-EINVAL;}returnxt_check_entry_match(elems,base+target_offset,
@@ -555,16 +555,9 @@ static int translate_table(struct xt_table_info *newinfo, void *entry0,if(i!=repl->num_entries)gotoout_free;-/* Check hooks all assigned */-for(i=0;i<NF_ARP_NUMHOOKS;i++){-/* Only hooks which are valid */-if(!(repl->valid_hooks&(1<<i)))-continue;-if(newinfo->hook_entry[i]==0xFFFFFFFF)-gotoout_free;-if(newinfo->underflow[i]==0xFFFFFFFF)-gotoout_free;-}+ret=xt_check_table_hooks(newinfo,repl->valid_hooks);+if(ret)+gotoout_free;if(!mark_source_chains(newinfo,repl->valid_hooks,entry0,offsets)){ret=-ELOOP;
@@ -702,16 +702,9 @@ translate_table(struct net *net, struct xt_table_info *newinfo, void *entry0,if(i!=repl->num_entries)gotoout_free;-/* Check hooks all assigned */-for(i=0;i<NF_INET_NUMHOOKS;i++){-/* Only hooks which are valid */-if(!(repl->valid_hooks&(1<<i)))-continue;-if(newinfo->hook_entry[i]==0xFFFFFFFF)-gotoout_free;-if(newinfo->underflow[i]==0xFFFFFFFF)-gotoout_free;-}+ret=xt_check_table_hooks(newinfo,repl->valid_hooks);+if(ret)+gotoout_free;if(!mark_source_chains(newinfo,repl->valid_hooks,entry0,offsets)){ret=-ELOOP;
@@ -720,16 +720,9 @@ translate_table(struct net *net, struct xt_table_info *newinfo, void *entry0,if(i!=repl->num_entries)gotoout_free;-/* Check hooks all assigned */-for(i=0;i<NF_INET_NUMHOOKS;i++){-/* Only hooks which are valid */-if(!(repl->valid_hooks&(1<<i)))-continue;-if(newinfo->hook_entry[i]==0xFFFFFFFF)-gotoout_free;-if(newinfo->underflow[i]==0xFFFFFFFF)-gotoout_free;-}+ret=xt_check_table_hooks(newinfo,repl->valid_hooks);+if(ret)+gotoout_free;if(!mark_source_chains(newinfo,repl->valid_hooks,entry0,offsets)){ret=-ELOOP;
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:35
From: Florian Westphal <fw@strlen.de>
Harmless from kernel point of view, but iptables assumes that this is
true when decoding a ruleset.
iptables walks the dumped blob from kernel, and, for each entry that
creates a new chain it prints out rule/chain information.
Base chains (hook entry points) are thus only shown when they appear
in the rule blob. One base chain that is referenced multiple times
in hook blob is then only printed once.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
@@ -1117,7 +1118,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)structxt_table_info*info=NULL;size_tsz=sizeof(*info)+size;-if(sz<sizeof(*info))+if(sz<sizeof(*info)||sz>=XT_MAX_TABLE_SIZE)returnNULL;/* __GFP_NORETRY is not fully supported by kvmalloc but it should
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:36
From: Florian Westphal <fw@strlen.de>
This is a very conservative limit (134217728 rules), but good
enough to not trigger frequent oom from syzkaller.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 3 +++
1 file changed, 3 insertions(+)
@@ -769,7 +769,9 @@ static int compat_table_info(const struct xt_table_info *info,memcpy(newinfo,info,offsetof(structxt_table_info,entries));newinfo->initial_entries=0;loc_cpu_entry=info->entries;-xt_compat_init_offsets(NFPROTO_ARP,info->number);+ret=xt_compat_init_offsets(NFPROTO_ARP,info->number);+if(ret)+returnret;xt_entry_foreach(iter,loc_cpu_entry,info->size){ret=compat_calc_entry(iter,info,loc_cpu_entry,newinfo);if(ret!=0)
@@ -1156,7 +1158,7 @@ static int translate_compat_table(struct xt_table_info **pinfo,structcompat_arpt_entry*iter0;structarpt_replacerepl;unsignedintsize;-intret=0;+intret;info=*pinfo;entry0=*pentry0;
@@ -1165,7 +1167,9 @@ static int translate_compat_table(struct xt_table_info **pinfo,j=0;xt_compat_lock(NFPROTO_ARP);-xt_compat_init_offsets(NFPROTO_ARP,compatr->num_entries);+ret=xt_compat_init_offsets(NFPROTO_ARP,compatr->num_entries);+if(ret)+gotoout_unlock;/* Walk through entries, checking offsets. */xt_entry_foreach(iter0,entry0,compatr->size){ret=check_compat_entry_size_and_hooks(iter0,info,&size,
@@ -933,7 +933,9 @@ static int compat_table_info(const struct xt_table_info *info,memcpy(newinfo,info,offsetof(structxt_table_info,entries));newinfo->initial_entries=0;loc_cpu_entry=info->entries;-xt_compat_init_offsets(AF_INET,info->number);+ret=xt_compat_init_offsets(AF_INET,info->number);+if(ret)+returnret;xt_entry_foreach(iter,loc_cpu_entry,info->size){ret=compat_calc_entry(iter,info,loc_cpu_entry,newinfo);if(ret!=0)
@@ -1407,7 +1409,9 @@ translate_compat_table(struct net *net,j=0;xt_compat_lock(AF_INET);-xt_compat_init_offsets(AF_INET,compatr->num_entries);+ret=xt_compat_init_offsets(AF_INET,compatr->num_entries);+if(ret)+gotoout_unlock;/* Walk through entries, checking offsets. */xt_entry_foreach(iter0,entry0,compatr->size){ret=check_compat_entry_size_and_hooks(iter0,info,&size,
@@ -950,7 +950,9 @@ static int compat_table_info(const struct xt_table_info *info,memcpy(newinfo,info,offsetof(structxt_table_info,entries));newinfo->initial_entries=0;loc_cpu_entry=info->entries;-xt_compat_init_offsets(AF_INET6,info->number);+ret=xt_compat_init_offsets(AF_INET6,info->number);+if(ret)+returnret;xt_entry_foreach(iter,loc_cpu_entry,info->size){ret=compat_calc_entry(iter,info,loc_cpu_entry,newinfo);if(ret!=0)
@@ -1414,7 +1416,7 @@ translate_compat_table(struct net *net,structcompat_ip6t_entry*iter0;structip6t_replacerepl;unsignedintsize;-intret=0;+intret;info=*pinfo;entry0=*pentry0;
@@ -1423,7 +1425,9 @@ translate_compat_table(struct net *net,j=0;xt_compat_lock(AF_INET6);-xt_compat_init_offsets(AF_INET6,compatr->num_entries);+ret=xt_compat_init_offsets(AF_INET6,compatr->num_entries);+if(ret)+gotoout_unlock;/* Walk through entries, checking offsets. */xt_entry_foreach(iter0,entry0,compatr->size){ret=check_compat_entry_size_and_hooks(iter0,info,&size,
@@ -632,10 +632,12 @@ int xt_compat_calc_jump(u_int8_t af, unsigned int offset)}EXPORT_SYMBOL_GPL(xt_compat_calc_jump);-voidxt_compat_init_offsets(u_int8_taf,unsignedintnumber)+intxt_compat_init_offsets(u8af,unsignedintnumber){xt[af].number=number;xt[af].cur=0;++return0;}EXPORT_SYMBOL(xt_compat_init_offsets);
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:39
From: Florian Westphal <fw@strlen.de>
no need to bother even trying to allocating huge compat offset arrays,
such ruleset is rejected later on anyway becaus we refuse to allocate
overly large rule blobs.
However, compat translation happens before blob allocation, so we should
add a check there too.
This is supposed to help with fuzzing by avoiding oom-killer.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
@@ -582,14 +582,8 @@ int xt_compat_add_offset(u_int8_t af, unsigned int offset, int delta){structxt_af*xp=&xt[af];-if(!xp->compat_tab){-if(!xp->number)-return-EINVAL;-xp->compat_tab=vmalloc(sizeof(structcompat_delta)*xp->number);-if(!xp->compat_tab)-return-ENOMEM;-xp->cur=0;-}+if(WARN_ON(!xp->compat_tab))+return-ENOMEM;if(xp->cur>=xp->number)return-EINVAL;
@@ -582,6 +582,8 @@ int xt_compat_add_offset(u_int8_t af, unsigned int offset, int delta){structxt_af*xp=&xt[af];+WARN_ON(!mutex_is_locked(&xt[af].compat_mutex));+if(WARN_ON(!xp->compat_tab))return-ENOMEM;
@@ -630,6 +634,8 @@ int xt_compat_init_offsets(u8 af, unsigned int number){size_tmem;+WARN_ON(!mutex_is_locked(&xt[af].compat_mutex));+if(!number||number>(INT_MAX/sizeof(structcompat_delta)))return-EINVAL;
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:41
From: Florian Westphal <fw@strlen.de>
Harmless from kernel point of view, but again iptables assumes that
this is true when decoding ruleset coming from kernel.
If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.
libiptc assumes that the policy is the last rule in the basechain, which
is only true for iptables-generated rulesets.
Unfortunately this needs code duplication -- the functions need the
struct layout of the rule head, but that is different for
ip/ip6/arptables.
NB: pr_warn could be pr_debug but in case this break rulesets somehow its
useful to know why blob was rejected.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/arp_tables.c | 17 ++++++++++++++++-
net/ipv4/netfilter/ip_tables.c | 17 ++++++++++++++++-
net/ipv6/netfilter/ip6_tables.c | 17 ++++++++++++++++-
3 files changed, 48 insertions(+), 3 deletions(-)
@@ -309,10 +309,13 @@ static int mark_source_chains(const struct xt_table_info *newinfo,for(hook=0;hook<NF_ARP_NUMHOOKS;hook++){unsignedintpos=newinfo->hook_entry[hook];structarpt_entry*e=entry0+pos;+unsignedintlast_pos,depth;if(!(valid_hooks&(1<<hook)))continue;+depth=0;+last_pos=pos;/* Set initial back pointer. */e->counters.pcnt=pos;
@@ -343,6 +346,8 @@ static int mark_source_chains(const struct xt_table_info *newinfo,pos=e->counters.pcnt;e->counters.pcnt=0;+if(depth)+--depth;/* We're at the start. */if(pos==oldpos)gotonext;
@@ -367,6 +372,9 @@ static int mark_source_chains(const struct xt_table_info *newinfo,if(!xt_find_jump_offset(offsets,newpos,newinfo->number))return0;++if(entry0+newpos!=arpt_next_entry(e))+++depth;}else{/* ... this is a fallthru */newpos=pos+e->next_offset;
@@ -377,8 +385,15 @@ static int mark_source_chains(const struct xt_table_info *newinfo,e->counters.pcnt=pos;pos=newpos;}+if(depth==0)+last_pos=pos;+}+next:+if(last_pos!=newinfo->underflow[hook]){+pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",+last_pos,newinfo->underflow[hook],hook);+return0;}-next:;}return1;}
@@ -378,10 +378,13 @@ mark_source_chains(const struct xt_table_info *newinfo,for(hook=0;hook<NF_INET_NUMHOOKS;hook++){unsignedintpos=newinfo->hook_entry[hook];structipt_entry*e=entry0+pos;+unsignedintlast_pos,depth;if(!(valid_hooks&(1<<hook)))continue;+depth=0;+last_pos=pos;/* Set initial back pointer. */e->counters.pcnt=pos;
@@ -410,6 +413,8 @@ mark_source_chains(const struct xt_table_info *newinfo,pos=e->counters.pcnt;e->counters.pcnt=0;+if(depth)+--depth;/* We're at the start. */if(pos==oldpos)gotonext;
@@ -434,6 +439,9 @@ mark_source_chains(const struct xt_table_info *newinfo,if(!xt_find_jump_offset(offsets,newpos,newinfo->number))return0;++if(entry0+newpos!=ipt_next_entry(e))+++depth;}else{/* ... this is a fallthru */newpos=pos+e->next_offset;
@@ -444,8 +452,15 @@ mark_source_chains(const struct xt_table_info *newinfo,e->counters.pcnt=pos;pos=newpos;}+if(depth==0)+last_pos=pos;+}+next:+if(last_pos!=newinfo->underflow[hook]){+pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",+last_pos,newinfo->underflow[hook],hook);+return0;}-next:;}return1;}
@@ -396,10 +396,13 @@ mark_source_chains(const struct xt_table_info *newinfo,for(hook=0;hook<NF_INET_NUMHOOKS;hook++){unsignedintpos=newinfo->hook_entry[hook];structip6t_entry*e=entry0+pos;+unsignedintlast_pos,depth;if(!(valid_hooks&(1<<hook)))continue;+depth=0;+last_pos=pos;/* Set initial back pointer. */e->counters.pcnt=pos;
@@ -428,6 +431,8 @@ mark_source_chains(const struct xt_table_info *newinfo,pos=e->counters.pcnt;e->counters.pcnt=0;+if(depth)+--depth;/* We're at the start. */if(pos==oldpos)gotonext;
@@ -452,6 +457,9 @@ mark_source_chains(const struct xt_table_info *newinfo,if(!xt_find_jump_offset(offsets,newpos,newinfo->number))return0;++if(entry0+newpos!=ip6t_next_entry(e))+++depth;}else{/* ... this is a fallthru */newpos=pos+e->next_offset;
@@ -462,8 +470,15 @@ mark_source_chains(const struct xt_table_info *newinfo,e->counters.pcnt=pos;pos=newpos;}+if(depth==0)+last_pos=pos;+}+next:+if(last_pos!=newinfo->underflow[hook]){+pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",+last_pos,newinfo->underflow[hook],hook);+return0;}-next:;}return1;}
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:42
From: Cong Wang <redacted>
As suggested by Eric, we need to make the xt_rateest
hash table and its lock per netns to reduce lock
contentions.
Cc: Florian Westphal <fw@strlen.de>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Cong Wang <redacted>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/netfilter/xt_rateest.h | 4 +-
net/netfilter/xt_RATEEST.c | 91 +++++++++++++++++++++++++++-----------
net/netfilter/xt_rateest.c | 10 ++---
3 files changed, 72 insertions(+), 33 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:43
From: Felix Fietkau <nbd@nbd.name>
Reduce code duplication and make it much easier to read
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_flow_table.c | 93 ++++++++++++++++---------------------------
1 file changed, 34 insertions(+), 59 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:44
From: Felix Fietkau <nbd@nbd.name>
Needed to remove a direct dependency on ipv6.ko from flowtable
infrastructure. Make it inline like ip_dst_mtu_maybe_forward().
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/ip6_route.h | 21 +++++++++++++++++++++
include/net/ipv6.h | 2 --
net/ipv6/ip6_output.c | 22 ----------------------
3 files changed, 21 insertions(+), 24 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:45
From: Felix Fietkau <nbd@nbd.name>
Reduces the number of cache lines touched in the offload forwarding
path. This is safe because PMTU limits are bypassed for the forwarding
path (see commit f87c10a8aa1e for more details).
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/netfilter/nf_flow_table.h | 2 ++
net/ipv4/netfilter/nf_flow_table_ipv4.c | 17 +++--------------
net/ipv6/netfilter/nf_flow_table_ipv6.c | 17 +++--------------
net/netfilter/nf_flow_table.c | 8 ++++++--
4 files changed, 14 insertions(+), 30 deletions(-)
diff --git a/net/netfilter/nf_flow_table.c b/net/netfilter/nf_flow_table_core.csimilarity index 100%rename from net/netfilter/nf_flow_table.crename to net/netfilter/nf_flow_table_core.c
--
2.11.0
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:48
From: "Gustavo A. R. Silva" <redacted>
Assign true or false to boolean variables instead of an integer value.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <redacted>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_lblc.c | 4 ++--
net/netfilter/ipvs/ip_vs_lblcr.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:48
From: Ahmed Abdelsalam <redacted>
This fixes Netfilter's bugzilla #1219.
Type 0 and 2 of the IPv6 Routing extension header are not handled
properlyby exthdr_init_raw() in src/exthdr.c
In order to fix the bug, we extended the "enum nft_exthdr_op" to
differentiate between rt, rt0, and rt2.
In this patch we extended the kernel implementation of nf_tables to
recognize the new options
Signed-off-by: Ahmed Abdelsalam <redacted>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/netfilter/nf_tables.h | 3 +++
net/netfilter/nft_exthdr.c | 3 +++
2 files changed, 6 insertions(+)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:49
From: Yi-Hung Wei <redacted>
Remove parameter 'family' in nf_conncount_count() and count_tree().
It is because the parameter is not useful after commit 625c556118f3
("netfilter: connlimit: split xt_connlimit into front and backend").
Signed-off-by: Yi-Hung Wei <redacted>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/netfilter/nf_conntrack_count.h | 1 -
net/netfilter/nf_conncount.c | 4 +---
net/netfilter/xt_connlimit.c | 4 ++--
3 files changed, 3 insertions(+), 6 deletions(-)
@@ -246,7 +245,6 @@ count_tree(struct net *net, struct rb_root *root,unsignedintnf_conncount_count(structnet*net,structnf_conncount_data*data,constu32*key,-unsignedintfamily,conststructnf_conntrack_tuple*tuple,conststructnf_conntrack_zone*zone){
@@ -259,7 +257,7 @@ unsigned int nf_conncount_count(struct net *net,spin_lock_bh(&nf_conncount_locks[hash%CONNCOUNT_LOCK_SLOTS]);-count=count_tree(net,root,key,data->keylen,family,tuple,zone);+count=count_tree(net,root,key,data->keylen,tuple,zone);spin_unlock_bh(&nf_conncount_locks[hash%CONNCOUNT_LOCK_SLOTS]);
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:51
From: Yi-Hung Wei <redacted>
Currently, nf_conncount_count() counts the number of connections that
matches key and inserts a conntrack 'tuple' with the same key into the
accounting data structure. This patch supports another use case that only
counts the number of connections where 'tuple' is not provided. Therefore,
proper changes are made on nf_conncount_count() to support the case where
'tuple' is NULL. This could be useful for querying statistics or
debugging purpose.
Signed-off-by: Yi-Hung Wei <redacted>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conncount.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -104,7 +104,7 @@ static unsigned int check_hlist(struct net *net,structnf_conn*found_ct;unsignedintlength=0;-*addit=true;+*addit=tuple?true:false;/* check the saved connections */hlist_for_each_entry_safe(conn,n,head,node){
@@ -117,7 +117,7 @@ static unsigned int check_hlist(struct net *net,found_ct=nf_ct_tuplehash_to_ctrack(found);-if(nf_ct_tuple_equal(&conn->tuple,tuple)){+if(tuple&&nf_ct_tuple_equal(&conn->tuple,tuple)){/**Justtobesurewehaveitonlyonceinthelist.*Weshouldnotseetuplestwiceunlesssomeonehooks
@@ -220,6 +220,9 @@ count_tree(struct net *net, struct rb_root *root,gotorestart;}+if(!tuple)+return0;+/* no match, need to insert new node */rbconn=kmem_cache_alloc(conncount_rb_cachep,GFP_ATOMIC);if(rbconn==NULL)
@@ -242,6 +245,9 @@ count_tree(struct net *net, struct rb_root *root,return1;}+/* Count and return number of conntrack entries in 'net' with particular 'key'.+*If'tuple'isnotnull,insertitintotheaccountingdatastructure.+*/unsignedintnf_conncount_count(structnet*net,structnf_conncount_data*data,constu32*key,
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-12 17:59:51
All existing keys, except the NFT_CT_SRC and NFT_CT_DST are assumed to
have strict datatypes. This is causing problems with sets and
concatenations given the specific length of these keys is not known.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Florian Westphal <fw@strlen.de>
---
include/uapi/linux/netfilter/nf_tables.h | 12 ++++++++--
net/netfilter/nft_ct.c | 38 ++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 2 deletions(-)
From: David Miller <davem@davemloft.net> Date: 2018-03-12 18:58:45
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 12 Mar 2018 18:58:50 +0100
The following patchset contains Netfilter/IPVS updates for your net-next
tree. This batch comes with more input sanitization for xtables to
address bug reports from fuzzers, preparation works to the flowtable
infrastructure and assorted updates. In no particular order, they are:
Sorry, I've seen enough. I'm not pulling this.
What is the story with this flow table stuff? I tried to ask you
about this before, but the response I was given was extremely vague
and did not answer my question at all.
This is a lot of code, and a lot of infrastructure, yet I see
no device using the infrastructure to offload conntack.
Nor can I see how this can possibly be even useful for such an
application. What conntrack offload needs are things completely
outside of what the flow table stuff provides. Mainly, they
require that the SKB is completely abstracted away from all of
the contrack code paths, and that the conntrack infrastructure
operates on an abstract packet metadata concept.
If you are targetting one specific piece of hardware with TCAMs
that you are familiar with. I'd like you to stop right there.
Because if that is all that this infrastructure can actually
be used for, it is definitely designed wrong.
This, as has been the case in the past, is what is wrong with
netfilter approach to supporting offloading. We see all of this
infrastructure before an actual working use case is provided for a
specific piece of hardware for a specific driver in the tree.
Nobody can evaluate whether the approach is good or not without
a clear driver change implementing support for it.
No other area of networking puts the cart before the horse like this.
I do not agree at all with the flow table infrastructure and I
therefore do not want to pull any more flow table changes into my tree
until there is an actual user of this stuff in that pull request which
actually works in a way which is useful for people. It is completely
dead and useless code currently.
If you disagree you have to not just say it, but show it with a driver
that successfully and cleanly uses this code to offload conntrack.
Meanwhile, remove the flow table commits from this pull request out of
your tree and ask me to pull in the rest.
Thanks.
From: Felix Fietkau <nbd@nbd.name> Date: 2018-03-12 19:30:05
On 2018-03-12 19:58, David Miller wrote:
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 12 Mar 2018 18:58:50 +0100
quoted
The following patchset contains Netfilter/IPVS updates for your net-next
tree. This batch comes with more input sanitization for xtables to
address bug reports from fuzzers, preparation works to the flowtable
infrastructure and assorted updates. In no particular order, they are:
Sorry, I've seen enough. I'm not pulling this.
What is the story with this flow table stuff? I tried to ask you
about this before, but the response I was given was extremely vague
and did not answer my question at all.
This is a lot of code, and a lot of infrastructure, yet I see
no device using the infrastructure to offload conntack.
Nor can I see how this can possibly be even useful for such an
application. What conntrack offload needs are things completely
outside of what the flow table stuff provides. Mainly, they
require that the SKB is completely abstracted away from all of
the contrack code paths, and that the conntrack infrastructure
operates on an abstract packet metadata concept.
If you are targetting one specific piece of hardware with TCAMs
that you are familiar with. I'd like you to stop right there.
Because if that is all that this infrastructure can actually
be used for, it is definitely designed wrong.
This, as has been the case in the past, is what is wrong with
netfilter approach to supporting offloading. We see all of this
infrastructure before an actual working use case is provided for a
specific piece of hardware for a specific driver in the tree.
Nobody can evaluate whether the approach is good or not without
a clear driver change implementing support for it.
No other area of networking puts the cart before the horse like this.
I do not agree at all with the flow table infrastructure and I
therefore do not want to pull any more flow table changes into my tree
until there is an actual user of this stuff in that pull request which
actually works in a way which is useful for people. It is completely
dead and useless code currently.
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.
Within OpenWrt, I'm working on a patch that makes the same available to
legacy netfilter as well. This is the reason for a lot of the core
refactoring that I did.
Hardware offload is still being worked on, not sure when we will have
the first driver ready. But as it stands now, the code is already very
useful and backported to OpenWrt for testing.
I think that in a couple of weeks this code will be ready to be enabled
by default in OpenWrt, which means that a lot of users' setups will get
a lot faster with no configuration change at all.
- Felix
From: David Miller <davem@davemloft.net> Date: 2018-03-12 20:01:23
From: Felix Fietkau <nbd@nbd.name>
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.
And the reason for which both were removed.
I don't see how you can avoid this problem.
I'm willing to be shown otherwise :-)
From: Felix Fietkau <nbd@nbd.name> Date: 2018-03-12 20:22:10
On 2018-03-12 21:01, David Miller wrote:
From: Felix Fietkau <nbd@nbd.name>
Date: Mon, 12 Mar 2018 20:30:01 +0100
quoted
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.
And the reason for which both were removed.
I don't see how you can avoid this problem.
I'm willing to be shown otherwise :-)
I don't think it suffers from the same issues, and if it does, it's a
lot easier to mitigate. The ruleset can easily be configured to only
offload connections that transferred a certain amount of data, handling
only bulk flows.
It's easy to put an upper limit on the number of offloaded connections,
and there's nothing in the code that just creates an offload entry per
packet or per lookup or something like that.
If you have other concerns, I'm sure we can address them with follow-up
patches, but as it stands, I think the code is already quite useful.
- Felix
From: Felix Fietkau <nbd@nbd.name>
Date: Mon, 12 Mar 2018 20:30:01 +0100
quoted
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?
From: Felix Fietkau <nbd@nbd.name>
Date: Mon, 12 Mar 2018 20:30:01 +0100
quoted
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.
David Miller [off-list ref] wrote:
[ flow tables ]
Ok, that seems to constrain the exposure.
We should talk at some point about how exposed conntrack itself is.
Sure, we can do that.
If you have specific scenarios (synflood, peer that opens
100k (legitimate) connections, perpetual-fin, etc) in mind let me know,
i do think that we could still do better in some cases.
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-03-14 18:38:54
Hi David,
Just for the record, this is a summary of what we have discussed so
far:
1) The existing flowtable infrastructure provides a software fast path
that is being useful for a valid number of usecases, in particular,
OpenWRT/LEDE developers/users are very enthusiastic about this.
Reason for this is that they have had no other choice rather than
loading out of tree kernel modules to enable fast forwarding paths
before this infrastructure has been mainlined. Fortunately, now
they have an upstream alternative that can help them get rid of those
modules. This fast path can be enabled very easily, actually one
single rule to select what flows follow the alternative path is
sufficient.
2) The software flowtable implementation is not affected by the
problems that flow/routing cache used to have. An attacker that
cycles through all key values by sending forged packets to fill up
the hashtable will get no entries. Ruleset policy specifies when
to offload entries into the flowtable, users can arbitrarily
decide when to push the flow into the flowtable, eg.
add rule filter forward ct status assured flow offload @x
Worst case scenario is that users need to see two packets, one on
each direction, to be able to place a flow in the flowtable.
3) There is no hardware offload integration yet. There's a public
patch - waiting to have a driver - that proposes ndo hooks, this
patch is not merged upstream. The flowtable design and the hardware
offload patch has been the result of conversations with many vendors
that represent a wide range of networking device classes, so it is
an individual effort by looking at one single device. Stateful
flowtable offload has been another main topic, pipeline is going
to stall a bit if we cannot make incremental progress towards that
direction.
Note that this batch was coming with a patch to reduce cache footprint
of the flowtable entries, so there is already working-in-progress
targeted at improving performance of this new software fast path.
Also, preparation works to introduce iptables support has been in the
radar while working on this.
We understand, we may have have spent more time in explaining all this
in the mailing list, we are trying to amend this now. Therefore, we
can probably convince someone here to write design documentation to be
placed on the Documentation/flowtable/ directory in the next pull
request if that makes it easier for the broader audience to understand
our effort and rise concerns, if any.
Thanks.
From: David Miller <davem@davemloft.net> Date: 2018-03-16 16:23:50
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 14 Mar 2018 19:38:48 +0100
Just for the record, this is a summary of what we have discussed so
far:
...
Note that this batch was coming with a patch to reduce cache footprint
of the flowtable entries, so there is already working-in-progress
targeted at improving performance of this new software fast path.
Also, preparation works to introduce iptables support has been in the
radar while working on this.
We understand, we may have have spent more time in explaining all this
in the mailing list, we are trying to amend this now. Therefore, we
can probably convince someone here to write design documentation to be
placed on the Documentation/flowtable/ directory in the next pull
request if that makes it easier for the broader audience to understand
our effort and rise concerns, if any.
From: Guy Shattah <hidden> Date: 2018-03-16 16:39:13
On 12/03/2018 20:58, David Miller wrote:
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 12 Mar 2018 18:58:50 +0100
quoted
The following patchset contains Netfilter/IPVS updates for your net-next
tree. This batch comes with more input sanitization for xtables to
address bug reports from fuzzers, preparation works to the flowtable
infrastructure and assorted updates. In no particular order, they are:
Sorry, I've seen enough. I'm not pulling this.
What is the story with this flow table stuff? I tried to ask you
about this before, but the response I was given was extremely vague
and did not answer my question at all.
This is a lot of code, and a lot of infrastructure, yet I see
no device using the infrastructure to offload conntack.
Hi David,
Pablo's code is a very welcome addition to the flow tables infrastructure.
We at Mellanox already have customers asking for Offload of Connection
Tracking.
While a complete hardware implementation is yet to arrive. Pablo's
contribution is blessed.
Using this infrastructure we are capable of completely offloading
connection tracking (Without TCP window validation)
and possibly do a complete offload once hardware support for TCP window
Validation shows up.
I'm currently working closely with Pablo to create the first driver
implementation to utilize
hardware offloading. Needless to say - prior to having hardware
implementation a software infrastructure is required.
Nor can I see how this can possibly be even useful for such an
application. What conntrack offload needs are things completely
outside of what the flow table stuff provides. Mainly, they
require that the SKB is completely abstracted away from all of
the contrack code paths, and that the conntrack infrastructure
operates on an abstract packet metadata concept.
Assuming that the software maintains the flow in the system,
it is reasonable to allow software do the connection establishment and
termination
and let the hardware do all the rest between (again - without TCP window
validation, unless a specialized hardware exists)
This, as has been the case in the past, is what is wrong with
netfilter approach to supporting offloading. We see all of this
infrastructure before an actual working use case is provided for a
specific piece of hardware for a specific driver in the tree.
Nobody can evaluate whether the approach is good or not without
a clear driver change implementing support for it.
I'm speaking on behalf of Mellanox.
Would one driver support as demonstration suffice?
Thanks,
Guy