netdev - Re: gso: Attempt to handle mega-GRO packets

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]

Message-ID: <20131107071742.GA31901@gondor.apana.org.au>
Date:	Thu, 7 Nov 2013 15:17:42 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	christoph.paasch@...ouvain.be, netdev@...r.kernel.org,
	hkchu@...gle.com, mwdalton@...gle.com
Subject: Re: gso: Attempt to handle mega-GRO packets

On Thu, Nov 07, 2013 at 03:15:31PM +0800, Herbert Xu wrote:
> On Wed, Nov 06, 2013 at 11:11:02PM -0800, Eric Dumazet wrote:
> > On Thu, 2013-11-07 at 08:43 +0800, Herbert Xu wrote:
> > 
> > > -		if (fskb != skb_shinfo(skb)->frag_list)
> > > -			goto perform_csum_check;
> > > +		if (fskb != skb_shinfo(skb)->frag_list) {
> > > +			struct sk_buff *nsegs;
> > > +
> > > +			if (nskb->len == len + doffset)
> > > +				goto perform_csum_check;
> > > +
> > > +			if (skb_has_frag_list(nskb)) {
> > > +				net_warn_ratelimited(
> > > +					"skb_segment: "
> > > +					"nested frag_list detected\n");
> > > +				kfree(nskb);
> > > +				err = -EINVAL;
> > > +				goto err;
> > > +			}
> > > +
> > > +			__skb_pull(nskb, doffset);
> > > +			skb_shinfo(nskb)->gso_size = mss;
> > > +			nsegs = skb_segment(nskb, features);
> > > +
> > 
> > This still assumes each skb found in frag_list has a exact multiple of
> > @mss bytes, and that the initial skb also ends at a right boundary.
> 
> So what in our stack violates this assumption? We've never handled
> arbitrary frag_lists in GSO and I see no reason why we need to start
> doing that now.
> 
> Also GRO was designed to only merge packets that satisfy these
> assumptions so that through GSO the original packets can be
> recovered without losing end-to-end connectivity.  This is really
> important for routers/switches.

Or perhaps you are saying that this doesn't handle page frags?
It should because each GRO frag_list entry looks just like any
boring old GSO packet filled with frags.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html