On 03/10/2017 07:10 AM, Leonard den Ottolander wrote: > A whopping gigabyte on 32 bit systems for arguments passed to an > executable. That sounds excessive. A use case of "ls *"-ing 128k files > with 32 byte names adds up to 4 MiB. That is 16 times what you need to > build a kernel. That sounds sufficient don't you think? And again, if > not, show us a use case. You have already been given use cases. * Mail spool directory with millions of files. * Large and complex build system with potentially long paths. Artificial limits are always going to cause problems, particularly when going from a higher limit to a lower limit. Your present justification is simply that nobody could have use for lots of arguments, which is not true, and that heap spraying needs to be stopped, which may be right but may not be the place to start. We should investigate other ways in which we can tackle the manner in which the zero day was carried out (like malloc metadata hardening for the default glibc allocator). Fundamentally our disagreement is about the risk versus value of the code in the kernel. Because we disagree about risk and value we will disagree about the action that needs to be taken. You have now been given the expert opinion of Joseph Myers and myself, so take that as you will. Deployed existing code stands, and the burden of proof is on _you_ to justify changing the code, not on me to justify all the use cases that users might have for the current implementation. Please invite more experts, security or otherwise, to come discuss on linux-api, the relative merits of _where_ we should be fixing attacks of this kind. -- Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
