Re: MAX_ARG_PAGES has no effect?

From: Ingo Molnar
Date: Thu Sep 01 2005 - 03:30:11 EST



* Andi Kleen <ak@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/