netdev - Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, do segmentation even for non IPSKB

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: <bbd992a7-fa9c-44de-876f-4e51721c60d5@stressinduktion.org>
Date:	Sat, 9 Jul 2016 11:10:38 -0400
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florian Westphal <fw@...len.de>,
	Shmulik Ladkani <shmulik.ladkani@...ellosystems.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, shmulik.ladkani@...il.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: ip_finish_output_gso: If skb_gso_network_seglen
 exceeds MTU, do segmentation even for non IPSKB_FORWARDED skbs

On 09.07.2016 05:00, Florian Westphal wrote:
> I am worried about this patch, skb_gso_validate_mtu is more costly than
> the ->flags & FORWARD check; everyone pays this extra cost.
> 
> What about setting IPCB FORWARD flag in iptunnel_xmit if
> skb->skb_iif != 0... instead?

That came to my mind first, too.

> Yet another possibility would be to reduce gso_size but that violates
> gro/gso symmetry...

If you see vxlan (or any other UDP encap protocol) as an in-kernel
tunnel solution/program acting as an end point it is actually legal to
modify gso_size in my opinion. Adding headers to an skb can also not be
symmetric in this case. I would not see anything bad happening because
of doing so. Do you? It is a matter of implementation. vxlan could also
eat all data and splice it anew onto a socket. It already doesn't care
about end-to-end pmtu consistency, so I can't see anything wrong with it.

To make this all safe one needs to handle the ttl in vxlan much better.
It needs to be inherited from the inner header, checked and properly
decremented on the outer header, so that vxlan itself acts as a full
blown router by itself. Otherwise endless loops are possible, as the
packet will always fit the size.

Bye,
Hannes