Date: Fri, 10 Apr 2009 12:20:08 -0500 From: Alan Cox <alc@cs.rice.edu> To: Marius Strobl <marius@alchemy.franken.de> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: memory protection and sbrk() Message-ID: <49DF7FC8.1000508@cs.rice.edu> In-Reply-To: <20090410113642.GA78551@alchemy.franken.de> References: <49D252EF.7060102@cs.rice.edu> <20090410113642.GA78551@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl wrote: > 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. > Thanks for the feedback. I haven't committed the patch yet because yours is the first response that I've received. At this point, I'm going to wait another 24 hours and commit the patch. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DF7FC8.1000508>