netdev - Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic skb handler

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

Message-ID: <20200427174038.7d2f2ed8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 27 Apr 2020 17:40:38 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Netdev <netdev@...r.kernel.org>,
        Adhipati Blambangan <adhipati@...a.io>,
        David Ahern <dsahern@...il.com>
Subject: Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic
 skb handler

On Mon, 27 Apr 2020 18:17:16 -0600 Jason A. Donenfeld wrote:
> On Mon, Apr 27, 2020 at 6:15 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Mon, 27 Apr 2020 17:45:12 -0600 Jason A. Donenfeld wrote:  
> > > > Okay, well, I'll continue developing the v3 approach a little further
> > > > -- making sure I have tx path handled too and whatnot. Then at least
> > > > something viable will be available, and you can take or leave it
> > > > depending on what you all decide.  
> > >
> > > Actually, it looks like egress XDP still hasn't been merged. So I
> > > think this patch should be good to go in terms of what it is.  
> >
> > TX and redirect don't require the XDP egress hook to function.  
> 
> Oh, you meant the TX and redirect actions returned from the ingress
> hook. Gotcha. The paths that those take don't appear to rely on having
> the fake header though, whereas the actual xdp_progs that run do rely
> on that, which is why it's added there.

Ack, but if the redirection target is a real Ethernet device it will
see a frame without a L2 header, right? Redirect from a real Ethernet
device to a L3 one and vice versa remains broken.