On 17.04, Hannes Frederic Sowa wrote: > > > 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.
Also correct, that argument hasn't come up so far. Its actually not too hard to handle, you need to keep track of which parts have been inspected to make a classification decision and make sure those parts are not overwritten. The TCP match does this statically, but we certainly could do this dynamically. The question again is how to keep geometry if things are actually overwritten, especially partially. Apparently all this troubly is being seen as worthwhile. > 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. I fully agree. > > Bye, > Hannes > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
