netdev - Re: question: update_pmtu doesn't update dst mtu

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: <5345021D.30505@securitycode.ru>
Date:	Wed, 9 Apr 2014 12:17:33 +0400
From:	"Ilya V. Matveychikov" <i.matveychikov@...uritycode.ru>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:	<netdev@...r.kernel.org>
Subject: Re: question: update_pmtu doesn't update dst mtu

On 08.04.2014 18:57, Hannes Frederic Sowa wrote:
> On Tue, Apr 08, 2014 at 01:03:43PM +0400, Ilya V. Matveychikov wrote:
>> Just another related question that gets me into trouble. Imagine that there is
>> an SKB that wants to be transmitted via that tunnel. Let's say that when it
>> comes to the TUNNEL device it has an MTU1 value. Now, someone updates the PMTU
>> for the route and mtu decreasing from MTU1 to MTU2, so MTU2 < MTU1.
>>
>> Given that, I suppose that our SKB must be (re)fragmented with ip_fragment as
>> it's size might be slightly bigger then the path can pass. The problem is that
>> ip_fragment uses dst_mtu(skb_dst(skb)) to determine the fragment size but it
>> still has MTU1 value as even update_pmtu(MTU2) was called as it doesn't leads to
>> real dst MTU updating.
>>
>> So the question is do I need to relookup the route or can I use the following
>> hack before ip_fragment:
>>
>> 	// dst_mtu(dst) shows MTU1
>> 	dst->ops->update_pmtu(dst, ..., MTU2)
>> 	...
>> 	skb_rtable(skb)->rt_pmtu = MTU2;
> 
> This might be a cached dst and you would alter the mtu for more nexthops than
> you intended.
> 
>> 	dst_set_expires(dst, 1);
> 
> With this you won't get around the time_after_eq check. You would have to
> tweak it manually to not retrieve dst_metrics value (this is what you
> intended?).
> 

Well, I missed it. Also, that was a hack and it's not the best solution...

>> 	...
>> 	// now, ip_fragment knows about real MTU value
>> 	ip_fragment(skb, output...)
> 
> Check if you can something do like
> skb_dst_drop(skb);
> new_dst = ip_route_output*(..., &fl4, ...);
> skb_dst_set(_noref)(skb, new_dst);
> 

Works fine, thanks! By the way, could you briefly explain why routes are
separated to input and output? What are the benefits?

> This should be a very unlikely path, I assume, so should not degrade
> performance that much.

Sure.

> 
> I wonder why you update the mtu in the output path.

Well, the problem is that I don't know how to properly handle packets whose DSTs
have changed while processing. The simple solution is to drop them. But I think
it's not the best case as we can re-fragment them if new MTU value is lesser
than the older one.

--
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