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: <20161103094239.13ac8ac2@pixies>
Date:   Thu, 3 Nov 2016 09:42:39 +0200
From:   Shmulik Ladkani <shmulik.ladkani@...il.com>
To:     Lance Richardson <lrichard@...hat.com>
Cc:     netdev@...r.kernel.org, fw@...len.de, jtluka@...hat.com,
        hannes@...essinduktion.org
Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in
 ip_finish_output_gso()

On Wed,  2 Nov 2016 16:36:17 -0400
Lance Richardson <lrichard@...hat.com> wrote:

> -	/* common case: fragmentation of segments is not allowed,
> -	 * or seglen is <= mtu
> +	/* common case: seglen is <= mtu
>  	 */
> -	if (((IPCB(skb)->flags & IPSKB_FRAG_SEGS) == 0) ||
> -	      skb_gso_validate_mtu(skb, mtu))
> +	if (skb_gso_validate_mtu(skb, mtu))
>  		return ip_finish_output2(net, sk, skb);

OK.
Resembles https://patchwork.ozlabs.org/patch/644724/ ;)

> -	if (skb_iif && !(df & htons(IP_DF))) {
> -		/* Arrived from an ingress interface, got encapsulated, with
> -		 * fragmentation of encapulating frames allowed.
> -		 * If skb is gso, the resulting encapsulated network segments
> -		 * may exceed dst mtu.
> -		 * Allow IP Fragmentation of segments.
> -		 */
> -		IPCB(skb)->flags |= IPSKB_FRAG_SEGS;
> -	}

The only potential issue I see removing this, is that the KNOWLEDGE of
the forwarding/tunnel-bridging usecases (that require a
skb_gso_validate_mtu check) is lost.

Meaning, if one decides (as claimed in the past) that locally generated
traffic must NOT go through fragmentation validation, then no one
remembers those other valid usecases (which are very specific and not
trivial to imagine) that MUST go through it; Therefore it can easily get
broken.

Maybe we can elaborate in the comment above the call to
skb_gso_validate_mtu in ip_finish_output_gso?

Best,
Shmulik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ