netdev - Re: [PATCH] net: Fragment large datagrams even when IP

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: <20160708.184129.1545084362199727100.davem@davemloft.net>
Date:	Fri, 08 Jul 2016 18:41:29 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	paul@...ma.org
Cc:	Alan.Davey@...aswitch.com, netdev@...r.kernel.org,
	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net
Subject: Re: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is
 set.

From: Paul Jakma <paul@...ma.org>
Date: Fri, 8 Jul 2016 13:55:11 +0100 (BST)

> On Wed, 15 Jun 2016, Alan Davey wrote:
> 
>> The only case that would break is that where an application relies on
>> the existing (documented as a bug) feature of getting an EMSGSIZE
>> return code in the case of an over-sized packet.  Applications that
>> perform their own fragmentation would be unaffected.
> 
> If this doesn't break existing applications that are doing
> fragmentation in userspace on raw sockets (e.g. Quagga ospfd), that's
> better.
> 
> As per previous email, I'd love to be able to get rid of that code and
> have the kernel do it for me. However, I also don't want to have to do
> anything other non-trivial to that code either. :)
> 
> The issue for us is, how would we know on any given host whether the
> kernel will do the fragmentation or whether ospfd has to do it? We
> need to be able to probe for that capability, surely?

The fact is, regardless of whether you could probe for the capability
or not, you have to keep the fragmentation code around forever.

And that is yet another reason I do not want to add this change at all.

It doesn't make any existing server any simpler, in fact it makes them
all more complicated because not only do they keep the fragmentation
code, they also get new logic to test for the feature that would allow
them to avoid using it.

Sorry, there is no way I am adding this, it's a net lose.