Messages in this thread | | | Date | Thu, 1 Sep 2005 10:30:33 +0200 | From | Ingo Molnar <> | Subject | Re: MAX_ARG_PAGES has no effect? |
| |
* 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/
| |