Re: MAX_ARG_PAGES has no effect?

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <ak@suse.de> wrote:

> On Thursday 01 September 2005 08:57, Ingo Molnar wrote:
> 
> > the whole thing should be reworked, so that there is no artificial limit
> > like MAX_ARG_PAGES. (it is after all just another piece of memory, in
> > theory)
> 
> Yes, a sysctl would probably lead to fragmentation problems and then 
> people would do ugly linked lists of buffers like poll.

not really fragmentation problems (the unit of allocation of argument 
pages is already a single page, and we do an array of pages), the real 
problem is the DoS - right now the array pages are unswappable while an 
exec() is ongoing.

> > If we do unconditional page-flipping then we fragment the argument
> > space, if we do both page-flipping if things are unfragmented and
> > well-aligned, and 'compact' the layout otherwise, we havent solved the
> > problem and have introduced a significant extra layer of complexity to
> > an already security-sensitive and fragile piece of code.
> 
> Page flipping = COW like fork would do?

i dont think we need COW. During execve() we are destroying the old 
context and are creating a completely new context, so in theory we could 
just 'flip over' the argument/environment pages (which are a parameter 
to sys_execve()) from the old mm into the newly created mm, without 
caring about the old mm.

> Not sure how this would work - the arguments of execve can be anywhere 
> in the address space and would presumably be often be in a 
> inconvenient place like in the middle of the stack of the new 
> executable.

yes, that's one of the issues. I've done some instrumentation some time 
ago and it seemed that the arguments are typically page-aligned, so the 
only issue would be to clear the partial page at the end of the 
arguments. But i still think the concept is volatile.

> > The best method i found was to get rid of bprm->pages[] and to directly
> > copy strings into the new mm via kmap (and to follow whatever RAM
> > allocation policies/limits there are for the new mm), but that's quite
> > ugly.
> 
> That sounds better.

yeah. It's also pretty laborous though.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/