netdev - Re: [PATCH bpf-next v6 2/6] bpf: add redirect

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: <20201012114130.6f57247f@carbon>
Date:   Mon, 12 Oct 2020 11:41:30 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>, ast@...nel.org,
        john.fastabend@...il.com, yhs@...com, netdev@...r.kernel.org,
        bpf@...r.kernel.org,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        brouer@...hat.com, Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
Subject: Re: [PATCH bpf-next v6 2/6] bpf: add redirect_peer helper

On Sun, 11 Oct 2020 20:50:12 -0600
David Ahern <dsahern@...il.com> wrote:

> On 10/11/20 10:16 AM, Daniel Borkmann wrote:
> >>
> >> This is awesome results and great work Daniel! :-)  
> 
> +1
> 
> >>
> >> I wonder if we can also support this from XDP, which can also native
> >> redirect into veth.  Originally I though we could add the peer netdev
> >> in the devmap, but AFAIK Toke showed me that this was not possible.  
> > 
> > I think it should be possible with similar principle. What was the
> > limitation that you ran into with devmap for XDP?  

If you add a device to devmap and afterwards move this device into a
namespace, then the device is removed from the devmap.  This is because
devmap detect/react on NETDEV_UNREGISTER and remove the net_device.

> Should just need an API to set the namespace of the redirect device -
> something that devmap can be extended to include now.

Perhaps for other devices being moved into a namespace.

Specifically for veth the XDP redirect (veth_ndo_xdp_xmit) already
pickup the peer net_device, and *queue* the xdp_frame, thus it's not
directly relevant for the XDP redirect (except we also have an
intermediate queue which is likely bad for the TCP_RR test).

I just tried to test native-XDP redirect into a veth with samples/bpf/
xdp_redirect_map, which doesn't work.  Packets are actually getting
silently dropped.  After digging into the kernel code, I realized this
is because the *peer*-veth device didn't have a XDP-prog loaded.  The
xdp_redirect_map loads a dummy-XDP prog on the veth-device (it can
see), as a way to enable the ndo_xdp_xmit (which we have discussed
before it a broken way to do this, but it have become a defacto way).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer