netdev - Re: [PATCH RFC v2] net: xdp: allow 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 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]

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