* Andi Kleen <[email protected]> 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 [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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |