netdev - Re: [PATCH V2 -next 0/5] don't exceed original maximum fragment size when refragmenting

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, 04 May 2015 19:29:25 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	fw@...len.de
Cc:	netdev@...r.kernel.org, hannes@...essinduktion.org,
	jesse@...ira.com, herbert@...dor.apana.org.au
Subject: Re: [PATCH V2 -next 0/5] don't exceed original maximum fragment
 size when refragmenting

From: Florian Westphal <fw@...len.de>
Date: Mon,  4 May 2015 22:54:43 +0200

> #2 keep fragments attached to reassembled
> 
> The idea is to attach the original skbs to the reassembled one, so the
> networking stack can choose which ones to use depending on the use
> case. Forwarding would operate on the original ones while code dealing
> with PACKET_HOST frames would use the reassembled one.
> 
> 	- We have the overhead to carry more skbs around, which we
>           currently don't do.

I disagree.  It is much more cheaper to save around a chain of smaller
than PAGE_SIZE SKB fragments, than have to allocate multi-order linear
SKB to hold the whole thing.

Furthermore, the allocation of the incoming SKB fragments has by
definition _ALREADY_ suceeded.  Therefore it is more likely to result
in successful passing of the frames through the host.

And I do not think you need to sets of packets.  We have SKB
interfaces that can pull headers out of the SKB even if it crosses
a frag boundary, yet returns a pointer directly to the object inside
of skb->data if it is fully contained inside of the linear area which
is the common case.

All of this infrastructure is there and optimized for handling
spaghetti fragged SKBs if that's what we end up receiving, use it.

All of these overlapping frag etc. issues are just details, and I am
still not convinced these cannot be handled properly.  Please try
harder.

> 	- This information cannot be stored in any of the currently
>           available fields in the skb or shared_info. That said, a new
>           pointer would be necessary in every skb, independently if it
>           is fragmented or not. This change does impact fast path and
>           skb size.

You could use the existing frag_list, or make a new member (but not
in sk_buff, but rather in the shinfo).

Just imposing a size limit does not preserve the geometry.

I consider this a show stopper, and I believe people like Herbert
Xu will agree with me.
--
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