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] [day] [month] [year] [list]

Date:   Tue, 25 Jun 2019 10:11:59 +0200
From:   Jakub Sitnicki <jakub@...udflare.com>
To:     Joe Stringer <joe@...d.net.nz>
Cc:     Florian Westphal <fw@...len.de>, netdev <netdev@...r.kernel.org>,
        bpf@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [RFC bpf-next 0/7] Programming socket lookup with BPF

On Fri, Jun 21, 2019 at 06:50 PM CEST, Joe Stringer wrote:
> On Fri, Jun 21, 2019 at 1:44 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>>
>> On Fri, Jun 21, 2019, 00:20 Joe Stringer <joe@...d.net.nz> wrote:
>>>
>>> On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>>> >
>>> > Hey Florian,
>>> >
>>> > Thanks for taking a look at it.
>>> >
>>> > On Tue, Jun 18, 2019 at 03:52 PM CEST, Florian Westphal wrote:
>>> > > 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)?
>>> >
>>> > The way I see it is that the problem is that we have mappings for
>>> > steering traffic into sockets split between two places: (1) the socket
>>> > lookup tables, and (2) the TPROXY rules.
>>> >
>>> > BPF programs that need to check if there is a socket the packet is
>>> > destined for have access to the socket lookup tables, via the mentioned
>>> > bpf_sk_lookup helper, but are unaware of TPROXY redirects.
>>> >
>>> > For TCP we're able to look up from BPF if there are any established,
>>> > request, and "normal" listening sockets. The listening sockets that
>>> > receive connections via TPROXY are invisible to BPF progs.
>>> >
>>> > Why are we interested in finding all listening sockets? To check if any
>>> > of them had SYN queue overflow recently and if we should honor SYN
>>> > cookies.
>>>
>>> Why are they invisible? Can't you look them up with bpf_skc_lookup_tcp()?
>>
>>
>> They are invisible in that sense that you can't look them up using the packet 4-tuple. You have to somehow make the XDP/TC progs aware of the TPROXY redirects to find the target sockets.
>
> Isn't that what you're doing in the example from the cover letter
> (reincluded below for reference), except with the new program type
> rather than XDP/TC progs?
>
>        switch (bpf_ntohl(ctx->local_ip4) >> 8) {
>         case NET1:
>                 ctx->local_ip4 = bpf_htonl(IP4(127, 0, 0, 1));
>                 ctx->local_port = 81;
>                 return BPF_REDIRECT;
>         case NET2:
>                 ctx->local_ip4 = bpf_htonl(IP4(127, 0, 0, 1));
>                 ctx->local_port = 82;
>                 return BPF_REDIRECT;
>         }
>
> That said, I appreciate that even if you find the sockets from XDP,
> you'd presumably need some way to retain the socket reference beyond
> XDP execution to convince the stack to guide the traffic into that
> socket, which would be a whole other effort. For your use case it may
> or may not make the most sense.

Granted we're just moving steering logic from one place to another, that
is from TPROXY rules to a BPF program.

The key here is that the BPF prog runs during inet_lookup.  This let's
"lower level" BPF progs like XDP or TC check if there is a destination
socket, without having to know about steering rules.

If there is a local socket, we don't need to do socket dispatch from
BPF. Just pass the packet up the stack.

-Jakub