From owner-freebsd-arch@FreeBSD.ORG Tue Mar 31 17:48:11 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 96595106566B for ; Tue, 31 Mar 2009 17:48:11 +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 622398FC26 for ; Tue, 31 Mar 2009 17:48:11 +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 8BEDC2C2C59; Tue, 31 Mar 2009 12:29:28 -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 RMuSbCBmZdzc; Tue, 31 Mar 2009 12:29:20 -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 7193A2C2AAC; Tue, 31 Mar 2009 12:29:20 -0500 (CDT) Message-ID: <49D252EF.7060102@cs.rice.edu> Date: Tue, 31 Mar 2009 12:29:19 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: arch@freebsd.org Content-Type: multipart/mixed; boundary="------------030705020004080800040606" Cc: Robert Watson , Alan Cox Subject: 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: Tue, 31 Mar 2009 17:48:11 -0000 This is a multi-part message in MIME format. --------------030705020004080800040606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. Thanks, Alan --------------030705020004080800040606 Content-Type: text/plain; name="sbrk.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sbrk.patch" Index: vm/vm_unix.c =================================================================== --- vm/vm_unix.c (revision 190506) +++ vm/vm_unix.c (working copy) @@ -117,7 +117,7 @@ goto done; } rv = vm_map_insert(&vm->vm_map, NULL, 0, old, new, - VM_PROT_ALL, VM_PROT_ALL, 0); + VM_PROT_RW, VM_PROT_ALL, 0); if (rv != KERN_SUCCESS) { error = ENOMEM; goto done; --------------030705020004080800040606--