From owner-freebsd-arch Fri Apr 6 17:28: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 05A2E37B422 for ; Fri, 6 Apr 2001 17:28:05 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f370QfY50900; Fri, 6 Apr 2001 17:26:41 -0700 (PDT) (envelope-from dillon) Date: Fri, 6 Apr 2001 17:26:41 -0700 (PDT) From: Matt Dillon Message-Id: <200104070026.f370QfY50900@earth.backplane.com> To: Seigo Tanimura Cc: arch@FreeBSD.ORG, bde@zeta.org.au, Seigo Tanimura Subject: Re: Mmap(2) should start just below stack (was: Re: Bumping up {MAX,DFL}*SIZ in i386) 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> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 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