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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 27 Apr 2020 15:08:55 -0600 From: "Jason A. Donenfeld" <Jason@...c4.com> To: Jakub Kicinski <kuba@...nel.org> Cc: Netdev <netdev@...r.kernel.org>, Adhipati Blambangan <adhipati@...a.io>, David Ahern <dsahern@...il.com>, Toke Høiland-Jørgensen <toke@...hat.com> Subject: Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic skb handler On Mon, Apr 27, 2020 at 3:00 PM Jakub Kicinski <kuba@...nel.org> wrote: > > On Mon, 27 Apr 2020 13:52:54 -0700 Jakub Kicinski wrote: > > On Mon, 27 Apr 2020 14:42:08 -0600 Jason A. Donenfeld wrote: > > > A user reported that packets from wireguard were possibly ignored by XDP > > > [1]. Apparently, the generic skb xdp handler path seems to assume that > > > packets will always have an ethernet header, which really isn't always > > > the case for layer 3 packets, which are produced by multiple drivers. > > > This patch fixes the oversight. If the mac_len is 0, then we assume > > > that it's a layer 3 packet, and in that case prepend a pseudo ethhdr to > > > the packet whose h_proto is copied from skb->protocol, which will have > > > the appropriate v4 or v6 ethertype. This allows us to keep XDP programs' > > > assumption correct about packets always having that ethernet header, so > > > that existing code doesn't break, while still allowing layer 3 devices > > > to use the generic XDP handler. > > > > Is this going to work correctly with XDP_TX? presumably wireguard > > doesn't want the ethernet L2 on egress, either? And what about > > redirects? > > > > I'm not sure we can paper over the L2 differences between interfaces. > > Isn't user supposed to know what interface the program is attached to? > > I believe that's the case for cls_bpf ingress, right? > > In general we should also ask ourselves if supporting XDPgeneric on > software interfaces isn't just pointless code bloat, and it wouldn't > be better to let XDP remain clearly tied to the in-driver native use > case. Seems nice to be able to use XDP everywhere as a means of packet processing without context switch, right?
Powered by blists - more mailing lists