From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 12:06:37 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4616106571B; Fri, 10 Apr 2009 12:06:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 322DF8FC20; Fri, 10 Apr 2009 12:06:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n3ABagQB078603; Fri, 10 Apr 2009 13:36:42 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n3ABagsH078602; Fri, 10 Apr 2009 13:36:42 +0200 (CEST) (envelope-from marius) Date: Fri, 10 Apr 2009 13:36:42 +0200 From: Marius Strobl To: Alan Cox Message-ID: <20090410113642.GA78551@alchemy.franken.de> References: <49D252EF.7060102@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D252EF.7060102@cs.rice.edu> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Robert Watson Subject: Re: memory protection and sbrk() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 12:06:40 -0000 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