On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote: > > Don't get me wrong, no software is safe from security issues, but if you > don't abstract your resources in the right way, you have more chance to > have experimence more problems. interesting point. The key part of iptables and nft design is heavy use of indirect calls. The execution of single iptable rule is ~3 indirect calls. Quite a lot worse in nft where every expression is an indirect call. If my math is correct even simplest nft rule will get to ~10. It was all fine until spectre2 was discovered and retpoline now adds 20-30 cycles for each indirect call. To put numbers in perspective the simple for(...) indirect_call(); loop without retpoline does ~500 M iterations per second on 2+Ghz xeon. clang -mretpoline gcc -mindirect-branch=thunk gcc -mindirect-branch=thunk-inline produce slightly different code with performance of 80-90 M iterations per second for the above loop. Looks like iptables/nft did not abstract the resources in the right way and now experiences more problems. CPUs will eventually be fixed and IBRS_ALL will become reality. Until then the kernel has to deal with the performance issues. bpf and the networking stack will suffer from retpoline as well and we need to work asap on devirtualization and other ideas. For xdp a single indirect call we do per packet (to call into bpf prog) is noticeable and we're experimenting with static_key-like approach to call bpf program with direct call. bpf_tail_calls will suffer too and cannot be accelerated as-is. To solve that we're working on dynamic linking via verifier improvements. C based bpf programs will use normal indirect calls, but verifier will replace indirect with direct at pointer update time. It's not going to be easy, but bpf and stack is fixable, whereas iptables/nft are going to suffer until fixed CPUs find their way into servers years from now. -- 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
