Date: Fri, 10 Apr 2009 13:36:42 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Alan Cox <alc@cs.rice.edu> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: memory protection and sbrk() Message-ID: <20090410113642.GA78551@alchemy.franken.de> In-Reply-To: <49D252EF.7060102@cs.rice.edu> References: <49D252EF.7060102@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 31, 2009 at 12:29:19PM -0500, Alan Cox wrote: > For as long as I can remember, FreeBSD's sbrk() has provided memory with > execute permission enabled. Before we branch for FreeBSD 8.0, I'd like > to try removing execute permission on this memory. > > On (non-PAE) i386 and a few of the embedded processors, this change will > have little tangible effect because there is no distinction in the > processor's MMU between read and execute permissions. > > On amd64, the only potential problems are likely with a very few > applications, like the JVM, that have their own internal implementation > of "malloc()" and generate code on the fly (i.e., JIT compilation). > However, I have verified that at least the Sun JVM works ok. I have > also checked that cvsup, which is based on Modula-3 and does not use the > standard malloc(), works ok. > > It's also worth noting that our standard malloc() has flip-flopped over > the last year or so in terms of whether it uses sbrk() or mmap() by > default to acquire memory. When it uses mmap(), it does not request > execute permission on the allocated memory. So, depending on whether > malloc() used mmap() or sbrk(), malloc() was returning memory with > different permissions. Consequently, I think that any application > problems due to the lack of execute permission on memory returned by > malloc() would have long since been detected. > > As a final sanity check, I would appreciate it if three kinds of users > would test the attached patch: (1) some IA64, PowerPC, and Sparc64 > users, (2) amd64-based users of "exotic" languages, like common lisp, > haskell, etc. and (3) amd64-based users of other JVMs, like kaffe. > > My plan is to commit the attached patch to HEAD on the 7th of April > unless I hear of problems. > The patch doesn't seem to cause ill effects on sparc64. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090410113642.GA78551>