From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 17:20:19 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 2533C1065675; Fri, 10 Apr 2009 17:20:19 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id E464E8FC19; Fri, 10 Apr 2009 17:20:18 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 5D8962C2ADC; Fri, 10 Apr 2009 12:20:18 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XcmY+7bCsqQR; Fri, 10 Apr 2009 12:20:09 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 675B72C2ACE; Fri, 10 Apr 2009 12:20:09 -0500 (CDT) Message-ID: <49DF7FC8.1000508@cs.rice.edu> Date: Fri, 10 Apr 2009 12:20:08 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Marius Strobl References: <49D252EF.7060102@cs.rice.edu> <20090410113642.GA78551@alchemy.franken.de> In-Reply-To: <20090410113642.GA78551@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 17:20:21 -0000 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