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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Ingo Molnar <[email protected]> wrote:

> * Linus Torvalds <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux