Date: Fri, 6 Apr 2001 17:26:41 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
Cc: arch@FreeBSD.ORG, bde@zeta.org.au, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
Subject: Re: Mmap(2) should start just below stack (was: Re: Bumping up {MAX,DFL}*SIZ in i386)
Message-ID: <200104070026.f370QfY50900@earth.backplane.com>
References: <200103191056.f2JAuox00630@rina.r.dl.itc.u-tokyo.ac.jp> <Pine.BSF.4.21.0103201350200.41190-100000@besplex.bde.org> <200103230517.f2N5HXx08605@rina.r.dl.itc.u-tokyo.ac.jp> <200104050506.f3556Xw28400@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
:I propose a solution against that problem by allocating the space just
:below the stack of a process for mmap(2), as depicted below:
:
:| Process Stack |
:+--------------------+ down to 3GB - max of RLIMIT_STACK
:|Reserved for Process|
:| Stack |
:+--------------------+ 3GB - max of RLIMIT_STACK
:| Mmap(2)ed space |
:| (mmap(2), dynamic | This may be fragmented.
:| linker, shared |
:| objects, etc) |
:+--------------------+ down to end of bss + max of RLIMIT_DATA
:| Mmap(2) Heap |
:+--------------------+ end of bss + max of RLIMIT_DATA
:|Reserved for Malloc |
:+--------------------+ up to end of bss + max of RLIMIT_DATA (break)
:| Malloc(3) Heap |
:
:As the end of bss + max of RLIMIT_DATA gets less likely to cross over
:mapped regions, we can provide much better flexibility of memory usage
:...
:Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org>
Hmm. Well, I like the idea of allocating from the end of the stack
downwards a whole lot better then the idea of allocating from the
end of RLIMIT_DATA upwards, but we have an issue in both cases that
we have to deal with.
suid-root programs often adjust resources upwards in order to avoid
potential root compromises due to allocation failures at just the
wrong time (coupled with a badly written program). Most commonly this
means RLIMIT_DATA will be increased and, of course, many programs will
also increase RLIMIT_DATA. However, the same problem with suid-root
programs exists for RLIMIT_STACK as well.
So using a RLIMIT_STACK based solution instead of RLIMIT_DATA only
partially solves the problem.
We also have a similar issue with fork(). Process A fork()'s and
adjusts the resource limits for the child process downward or upward.
--
One thing to note is that anonymous memory can trivially be allocated
with mmap(), and will end up in the mmap space rather then the DATA/RSS
space. Thus we have a potential solution that does not require any
kernel modifications at all - use mmap() to allocate memory. Of course,
at the moment, programs that allocate huge amounts of memory with malloc()
would have to be aware of this fact to take advantage of it. I don't know
what the correct solution is, but I am leary of making the mmap() space
relative to user-adjustable resources.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104070026.f370QfY50900>