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]

Date:   Mon, 27 Apr 2020 17:00:02 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Jakub Kicinski <kuba@...nel.org>
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, Apr 27, 2020 at 3:31 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 27 Apr 2020 23:14:05 +0200 Toke Høiland-Jørgensen wrote:
> > Jakub Kicinski <kuba@...nel.org> writes:
> > > 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.
> >
> > I was mostly ignoring generic XDP for a long time for this reason. But
> > it seems to me that people find generic XDP quite useful, so I'm no
> > longer so sure this is the right thing to do...
>
> I wonder, maybe our documentation is not clear. IOW we were saying that
> XDP is a faster cls_bpf, which leaves out the part that XDP only makes
> sense for HW/virt devices.
>
> Kinda same story as XDP egress, folks may be asking for it but that
> doesn't mean it makes sense.
>
> Perhaps the original reporter realized this and that's why they
> disappeared?
>
> My understanding is that XDP generic is aimed at testing and stop gap
> for drivers which don't implement native. Defining behavior based on
> XDP generic's needs seems a little backwards, and risky.
>
> That said, I don't feel particularly strongly about this.

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.