netdev - Re: [PATCH RFC 0/3] Support fraglist GRO/GSO

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:   Fri, 25 Jan 2019 09:14:17 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC:     Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH RFC 0/3] Support fraglist GRO/GSO

On Mon, Jan 14, 2019 at 12:09:22PM -0500, Willem de Bruijn wrote:
> On Mon, Jan 14, 2019 at 7:50 AM Steffen Klassert
> <steffen.klassert@...unet.com> wrote:
> > On Sun, Dec 23, 2018 at 08:15:40PM -0500, Willem de Bruijn wrote:
> > >
> > > I would prefer to split the patch that adds UDP GRO on the forwarding
> > > path into one that enables it for existing GRO (the hack you refer to
> > > above) and a second one to optionally convert to listified processing.
> >
> > The hack was to skip the socket lookup. While that was ok for a
> > forwarding test, it will affect the local receive path of course.
> >
> > Currently, I check if there is a GRO capable socket. If yes,
> > do standard GRO. If no, do listified GRO regardless if packets
> > are going to be forwarded or locally received. So UDP GRO is
> > always on with this.
> 
> I understand. What I suggest is to split into two: enable GRO on the
> forwarding path independently from converting the method to listified
> GRO.

Ok, will do that in the next patchset.

> > We would need to do an early route lookup to check if the packets
> > are going to be forwarded or locally received. The current patchset
> > does not implement this, but could be done. Maybe doing a route
> > lookup based on some static key that will be enabled when forwarding
> > on the receiving device is enabled.
> >
> > But even if the route lookup tell us that the packet should go the
> > forwarding path, netfilter (bpfilter?) could reroute the packet.
> > If we do an early route lookup, it would be good to have some early
> > netfilter (bpfilter?) too, so that we can know which path the packets
> > go. In this case we could do listified GRO even for TCP, if we can
> > know that we have to do software segmentation later on.
> >
> > Btw. do we already have hardware that can do UDP LSO?
> 
> Yes, mlx5
> 
> I don't think that the route lookup is needed. If listified is cheaper
> for local delivery, too, then we can make that the default unless a
> device is active with h/w offload and ip forwarding is enabled. If it
> isn't, then use it iff ip forwarding is enabled. I think it's fine to
> mispredict between the two in edge cases with netfilter mangling, as
> long as all paths can correctly handle both types of GRO packets.

I'd need at least a route lookup for my usecase, because listified
GRO is always cheaper when a xfrm transformation is needed (even for
TCP). In this case is software GSO needed. So I'd need to either have
an early route lookup or maybe some early ingress hook where a route
lookup could be imlemented in.

> > >
> > > For both existing UDP GRO and listified, we should verify that this is
> > > not a potential DoS vector before enabling by default.
> >
> > Yes, but should'nt this be the same as with TCP GRO?
> 
> That is by now well-tested. I don't think we can simply assume
> equivalence for UDP, also because that is easier to spoof.

What would be a good test for this? I played with masscan
and hping3, but did not notice any differences between
net-next and net-next + UDP GRO patches.