Re: [PATCH] binfmt: turn MAX_ARG_PAGES into a sysctl tunable

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > I totally re-organized how execve() allocates the new mm at an execve 
> > several years ago (it used to re-use the old MM if it could), and that 
> > was so that we count just remove the brpm->page array, and just 
> > install the pages directly into the destination.
> > 
> > That was in 2002. I never actually got around to doing it ;(.
> 
> i thought about your "map execve pages directly into target" (since the 
> source gets destroyed anyway) suggestion back then, and unfortunately it 
> gets quite complex.
> 
> Firstly, if setenv is done and the array of strings gets larger, glibc 
> realloc()s it and the layout of the environment gets 'fragmented'. 
> Ulrich was uneasy about passing a fragmented environment to the target 
> task - it's not sure that no app would break. Secondly, for security 
> reasons we have to memset all the memory around fragmented strings. So 
> we might end up doing _alot_ of memsetting in some cases, if the string 
> space happens to be fragmented. So while the current method is slow and 
> uses persistent memory, it at least "compresses" the layout of the 
> environment (and arguments) at every exec() time and thus avoids these 
> sorts of problems.
> 
> And this is a real problem for real applications and is being complained 
> about alot by shops that do alot of development and have scrips around 
> large filesystem hierarchies. (and who got used to their scripts working 
> on other unices just fine)
> 
> Lets at least give root the chance to increase this limit and go with 
> the dumb and easy patch i posted years ago. [...]

it's almost 5 years old:

  http://people.redhat.com/mingo/execve-patches/exec-argsize-2.4.10-A3

( purely making the limit dynamic is not enough - bprm->pages needs to
  become kmalloc()ed, plus i added a bprm->nr_pages so that decreasing 
  the limit becomes safe too.)

	Ingo