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

Ingo Molnar
2006-06-26T22:51:42Z

* 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