netdev - Re: [RFC bpf-next 0/7] Programming socket lookup with BPF

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: <20190618135258.spo6c457h6dfknt2@breakpoint.cc>
Date:   Tue, 18 Jun 2019 15:52:58 +0200
From:   Florian Westphal <fw@...len.de>
To:     Jakub Sitnicki <jakub@...udflare.com>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        kernel-team@...udflare.com
Subject: Re: [RFC bpf-next 0/7] Programming socket lookup with BPF

Jakub Sitnicki <jakub@...udflare.com> wrote:
>  - XDP programs using bpf_sk_lookup helpers, like load balancers, can't
>    find the listening socket to check for SYN cookies with TPROXY redirect.

Sorry for the question, but where is the problem?
(i.e., is it with TPROXY or bpf side)?

>  - TPROXY takes a reference to the listening socket on dispatch, which
>    raises lock contention concerns.

FWIW this could be avoided in similar way as to how we handle noref dsts.

The only reason we need to take the reference at the moment is because
once skb leaves the TPROXY target hook, the skb could leave rcu
protection as well at some point (nfqueue for example).

Maybe its even enough to move reference taking to nfqueue and add
'noref' destructor, that would allow skb_steal_sock to propagate
refcounted value in __inet_lookup_skb.

So, at least for this part I don't see a technical reason why this
has to grab a reference for listener socket.

>  - Traffic steering configuration is split over several iptables rules, at
>    least one per service, which makes configuration changes error prone.

Could you perhaps sketch an example ruleset (doesn't have to be complete
nor parse-able by itpables-restore), I would just like to understand if
there is any room for improvement on netfilter/iptables/nft side.

Thanks,
Florian