| 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
| ||
|
Message-ID: <87ftcpyy9l.fsf@toke.dk> Date: Mon, 27 Apr 2020 13:16:22 +0200 From: Toke Høiland-Jørgensen <toke@...hat.com> To: "Jason A. Donenfeld" <Jason@...c4.com>, netdev@...r.kernel.org Cc: "Jason A. Donenfeld" <Jason@...c4.com> Subject: Re: [PATCH RFC v2] net: xdp: allow for layer 3 packets in generic skb handler "Jason A. Donenfeld" <Jason@...c4.com> writes: > A user reported a few days ago that packets from wireguard were possibly > ignored by XDP [1]. We haven't heard back from the original reporter to > receive more info, so this here is mostly speculative. Successfully nerd > sniped, Toke and I started poking around. Toke noticed that 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 is untested, but I > wanted to gauge interest in this approach: 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. Seems to me like this would work; let's see if anyone else has any comments :) -Toke
Powered by blists - more mailing lists