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]

Date:   Tue, 20 Feb 2018 17:52:54 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     David Miller <davem@...emloft.net>, phil@....cc,
        laforge@...monks.org, fw@...len.de, daniel@...earbox.net,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

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.