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@xxxxxxxxxxxxxx> wrote:
>>
>> On Fri, Jun 21, 2019, 00:20 Joe Stringer <joe@xxxxxxxxxxx> wrote:
>>>
>>> On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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
