netdev - Re: [PATCH bpf v2 0/5] bpf: Allow any source IP in bpf_skb_set_tunnel

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]

Message-ID: <20220719204013.GA90459@Mem>
Date:   Tue, 19 Jul 2022 22:40:13 +0200
From:   Paul Chaignon <paul@...valent.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Nikolay Aleksandrov <razor@...ckwall.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        John Fastabend <john.fastabend@...il.com>,
        Kaixi Fan <fankaixi.li@...edance.com>,
        Yonghong Song <yhs@...com>
Subject: Re: [PATCH bpf v2 0/5] bpf: Allow any source IP in
 bpf_skb_set_tunnel_key

On Tue, Jul 19, 2022 at 10:44:52AM -0700, Alexei Starovoitov wrote:
> On Mon, Jul 18, 2022 at 11:58 PM Nikolay Aleksandrov
> <razor@...ckwall.org> wrote:
> >
> > On 18/07/2022 18:53, Paul Chaignon wrote:
> > > Commit 26101f5ab6bd ("bpf: Add source ip in "struct bpf_tunnel_key"")
> > > added support for getting and setting the outer source IP of encapsulated
> > > packets via the bpf_skb_{get,set}_tunnel_key BPF helper. This change
> > > allows BPF programs to set any IP address as the source, including for
> > > example the IP address of a container running on the same host.
> > >
> > > In that last case, however, the encapsulated packets are dropped when
> > > looking up the route because the source IP address isn't assigned to any
> > > interface on the host. To avoid this, we need to set the
> > > FLOWI_FLAG_ANYSRC flag.
> > >
> > > Changes in v2:
> > >   - Removed changes to IPv6 code paths as they are unnecessary.
> > >
> > > Paul Chaignon (5):
> > >   ip_tunnels: Add new flow flags field to ip_tunnel_key
> > >   vxlan: Use ip_tunnel_key flow flags in route lookups
> > >   geneve: Use ip_tunnel_key flow flags in route lookups
> > >   bpf: Set flow flag to allow any source IP in bpf_tunnel_key
> > >   selftests/bpf: Don't assign outer source IP to host
> > >
> > >  drivers/net/geneve.c                                 |  1 +
> > >  drivers/net/vxlan/vxlan_core.c                       | 11 +++++++----
> > >  include/net/ip_tunnels.h                             |  1 +
> > >  net/core/filter.c                                    |  1 +
> > >  tools/testing/selftests/bpf/prog_tests/test_tunnel.c |  1 -
> > >  5 files changed, 10 insertions(+), 5 deletions(-)
> > >
> >
> > Looks good, for the set:
> > Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>
> 
> vxlan_test is failing.
> See BPF CI link in patchwork.

I've seen that today and was able to reproduce. It's most likely because
the reply packet is dropped by the stack given the destination address
is not local. The easiest way to update the test is probably to rewrite
the destination address with another BPF program on ingress. Anyway,
thanks for the heads up!

I'm also trying to figure out how I got a passing test before, but most
likely explanation is that my test changes were overwritten because of
the workflow bug [1]

1 - https://github.com/kernel-patches/vmtest/pull/95

> 
> Also it's too late for 'bpf' tree. Pls tag bpf-next on respin.

Will do.