Date: Mon, 23 Apr 2001 23:54:49 +0900
From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, arch@FreeBSD.ORG, bde@zeta.org.au
Subject: Re: Mmap(2) should start just below stack (was: Re: Bumping up {MAX,DFL}*SIZ in i386)
Message-ID: <200104231454.f3NEsnN26340@bunko.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>
In-Reply-To: <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> <200104070026.f370QfY50900@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Apr 2001 17:26:41 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> said: dillon> :| Process Stack | dillon> :+--------------------+ down to 3GB - max of RLIMIT_STACK dillon> :|Reserved for Process| dillon> :| Stack | dillon> :+--------------------+ 3GB - max of RLIMIT_STACK dillon> :| Mmap(2)ed space | dillon> :| (mmap(2), dynamic | This may be fragmented. dillon> :| linker, shared | dillon> :| objects, etc) | dillon> :+--------------------+ down to end of bss + max of RLIMIT_DATA dillon> :| Mmap(2) Heap | dillon> :+--------------------+ end of bss + max of RLIMIT_DATA dillon> :|Reserved for Malloc | dillon> :+--------------------+ up to end of bss + max of RLIMIT_DATA (break) dillon> :| Malloc(3) Heap | dillon> suid-root programs often adjust resources upwards in order to avoid dillon> potential root compromises due to allocation failures at just the dillon> wrong time (coupled with a badly written program). Most commonly this dillon> means RLIMIT_DATA will be increased and, of course, many programs will dillon> also increase RLIMIT_DATA. However, the same problem with suid-root dillon> programs exists for RLIMIT_STACK as well. dillon> So using a RLIMIT_STACK based solution instead of RLIMIT_DATA only dillon> partially solves the problem. dillon> We also have a similar issue with fork(). Process A fork()'s and dillon> adjusts the resource limits for the child process downward or upward. At that point, we have to reserve a certain size of an address region either below the max of RLIMIT_STACK or above the max of RLIMIT_DATA. As the reserved address space is likely to be unused in many cases, the size should be kept small. While the size of the data handled by a process can go up to gigabytes, the size of the stack consumed by a process is only up to several ten megabytes. (unless you are trying to solve a problem that cannot be solved by a Turing machine :) Hence our option should be to reserve a region down to 3GB - MAXSSIZ (which is the lower limit of RLIMIT_STACK) and possibly an additional safety zone below the stack. Then a user process vm space looks something like this: | Process Stack | +--------------------+ down to 3GB - max of RLIMIT_STACK |Reserved for Process| | Stack | +--------------------+ 3GB - max of RLIMIT_STACK |Reserved for growth | | of RLIMIT_STACK | +--------------------+ 3GB - MAXSSIZ | Safety zone for | | buffer overflow | +--------------------+ 3GB - (MAXSSIZ + SAFETY_ZONE_SIZE) | 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 | It should be enough for SAFETY_ZONE_SIZE to be about 16-32MB. Since MAXSSIZ + SAFETY_ZONE_SIZE is much smaller than MAXDSIZE, reserving the stack space and the safety zone is less likely to be the obstacle to reserve a large mmap(2) space than now. -- Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> 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?200104231454.f3NEsnN26340>