From owner-freebsd-arch Mon Apr 23 8:27:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id B10DB37B423 for ; Mon, 23 Apr 2001 08:27:46 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with UUCP id f3NFPAV75414 ; Tue, 24 Apr 2001 00:25:10 +0900 (JST) Received: (from root@localhost) by sohgo.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W) with UUCP id f3NFHCU01590 ; Tue, 24 Apr 2001 00:17:12 +0900 (JST) Received: from bunko.nkth.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by bunko.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.11.1+3.4W/3.7W) with ESMTP id f3NEsnN26340 ; Mon, 23 Apr 2001 23:54:50 +0900 (JST) Message-Id: <200104231454.f3NEsnN26340@bunko.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 23 Apr 2001 23:54:49 +0900 From: Seigo Tanimura To: Matt Dillon Cc: Seigo Tanimura , 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) In-Reply-To: <200104070026.f370QfY50900@earth.backplane.com> References: <200103191056.f2JAuox00630@rina.r.dl.itc.u-tokyo.ac.jp> <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> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 6 Apr 2001 17:26:41 -0700 (PDT), Matt Dillon 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message