Message-ID: <CAOftzPj+H1fep3D2E=zZr_ys=cdwT9Ci7=evHQirzc8C6toqfA@mail.gmail.com>
Date:   Tue, 17 Mar 2020 19:03:45 -0700
From:   Joe Stringer <joe@...d.net.nz>
To:     Joe Stringer <joe@...d.net.nz>
Cc:     Lorenz Bauer <lmb@...udflare.com>, Martin KaFai Lau <kafai@...com>,
        bpf <bpf@...r.kernel.org>, netdev <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH bpf-next 3/7] bpf: Add socket assign support

On Tue, Mar 17, 2020 at 6:10 PM Joe Stringer <joe@...d.net.nz> wrote:
>
> On Tue, Mar 17, 2020 at 3:10 AM Lorenz Bauer <lmb@...udflare.com> wrote:
> >
> > On Tue, 17 Mar 2020 at 03:06, Joe Stringer <joe@...d.net.nz> wrote:
> > >
> > > On Mon, Mar 16, 2020 at 3:58 PM Martin KaFai Lau <kafai@...com> wrote:
> > > >
> > > > On Thu, Mar 12, 2020 at 04:36:44PM -0700, Joe Stringer wrote:
> > > > > Add support for TPROXY via a new bpf helper, bpf_sk_assign().
> > > > >
> > > > > This helper requires the BPF program to discover the socket via a call
> > > > > to bpf_sk*_lookup_*(), then pass this socket to the new helper. The
> > > > > helper takes its own reference to the socket in addition to any existing
> > > > > reference that may or may not currently be obtained for the duration of
> > > > > BPF processing. For the destination socket to receive the traffic, the
> > > > > traffic must be routed towards that socket via local route, the socket
> > > > I also missed where is the local route check in the patch.
> > > > Is it implied by a sk can be found in bpf_sk*_lookup_*()?
> > >
> > > This is a requirement for traffic redirection, it's not enforced by
> > > the patch. If the operator does not configure routing for the relevant
> > > traffic to ensure that the traffic is delivered locally, then after
> > > the eBPF program terminates, it will pass up through ip_rcv() and
> > > friends and be subject to the whims of the routing table. (or
> > > alternatively if the BPF program redirects somewhere else then this
> > > reference will be dropped).
> >
> > Can you elaborate what "an appropriate routing configuration" would be?
> > I'm not well versed with how routing works, sorry.
>
> [...]
>
> > Do you think being subject to the routing table is desirable, or is it an
> > implementation trade-off?
>
> I think it's an implementation trade-off.

Perhaps it's worth expanding on this a bit more. There's always the
tradeoff of solving your specific problem vs. introducing
functionality that will integrate with the rest of the stack. In some
sense, I would like a notion here of "shortcut this traffic directly
to the socket", it will solve my problem but it's quite specific to
that so there's not much room for sharing the usage. It could still be
very useful to some use cases, but alternatives may support use cases
you hadn't thought of in the first place. Maybe there's a more
incremental path to achieving my goal through an implementation like
this.

The current design of bpf_sk_assign() in this series defers to the
stack a bit more than alternatives may do (thinking eg a socket
redirect function "bpf_sk_redirect()"). It says "this is best-effort";
if you wanted to, you could still override this functionality with
iptables tproxy rules. You could choose to route the traffic
differently (although through the exploration with Martin above for
now this will have fairly limited options unless we make additional
changes..). Glancing through the existing eBPF API, you could assign
the socket to the skb then subsequently use things like
bpf_get_socket_cookie() to fetch the cookie out. For all I know,
someone will come up with some nifty future idea that makes use of the
idea "we associate the socket with the skb" to solve a use case I
haven't thought of, and that could exist either within the bpf@tc hook
or after.

Powered by blists - more mailing lists