From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Frederic Sowa Subject: Re: [PATCH -next 0/3] net: cap size to original frag size when refragmenting Date: Fri, 17 Apr 2015 01:16:01 +0200 Message-ID: <1429226161.2585513.254850009.26B43D4D@webmail.messagingengine.com> References: <20150416052357.GA3285@acer.localdomain> <20150416052904.GA12648@gondor.apana.org.au> <1429186302.1075929.254563877.238D8F77@webmail.messagingengine.com> <20150416.114323.2122666447487730641.davem@davemloft.net> <1429200805.1141475.254665081.0E1724C4@webmail.messagingengine.com> <20150416204702.GA20616@gondor.apana.org.au> <20150416205646.GB4020@acer.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: David Miller , Florian Westphal , netdev@vger.kernel.org To: Patrick McHardy , Herbert Xu Return-path: Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60789 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbbDPXQB (ORCPT ); Thu, 16 Apr 2015 19:16:01 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4D08F209C5 for ; Thu, 16 Apr 2015 19:16:01 -0400 (EDT) In-Reply-To: <20150416205646.GB4020@acer.localdomain> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Apr 16, 2015, at 22:56, Patrick McHardy wrote: > On 17.04, Herbert Xu wrote: > > On Thu, Apr 16, 2015 at 06:13:25PM +0200, Hannes Frederic Sowa wrote: > > > > > > So currently we have one fast path, that is: we are not fragmented, we > > > get out non-fragmented, none of this code is ever touched and no > > > problem. > > > > > > We don't want to mak this more complex, but > > > > You should read Dave's other email where he gives you an obvious > > solution. If you have to modify the skb then you don't have to > > worry about the original fragments. > > > > But if you only read the skb then don't linearise it completely > > and keep the original fragments. > > Yes, I was just responding to that. We need an additional member > in the skb, but then this part is quite simple. I guess you refer to the solution of using the fragmented list of packets to do checks. I don't think it will be that simple to peek into all the different skbs if the fragments are split in the header. Splitting fragments in the header is the 1x1 of firewall by-passing attacks, so we should certainly handle it correctly. Logic off peeking into fragments and splitting fragments must be logically consent all the time, with all netfilter helpers in the tree. I don't think the additional checks in fast-path are in any way justified. Bye, Hannes