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, 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ