From owner-freebsd-arch@FreeBSD.ORG Mon May 30 08:46:04 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F8416A41C; Mon, 30 May 2005 08:46:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E78CB43D48; Mon, 30 May 2005 08:46:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 8923146B4D; Mon, 30 May 2005 04:46:03 -0400 (EDT) Date: Mon, 30 May 2005 09:46:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Suleiman Souhlal In-Reply-To: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> Message-ID: <20050530093845.T52379@fledge.watson.org> References: <40BB7DA9-472A-476A-B6B0-8C3DFDCC9060@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: [PATCH] randomized mmap 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: Mon, 30 May 2005 08:46:04 -0000 On Sun, 29 May 2005, Suleiman Souhlal wrote: > The patch at http://people.freebsd.org/~ssouhlal/testing/ > mmap_random-20050528.diff implements random mmap addresses (unless of > course MAP_FIXED is being used), again from OpenBSD. This behavior can > be disabled setting the vm.mmap_random sysctl to 0. I think this could > greatly increase memory fragmentation, so I'm not sure it would be such > a good idea to have it on by default. Also, it doesn't really make > attacks unfeasable, but the implementation is so simple that I don't > think we really lose anything by letting users decide if they want to > enable it or not. Presumably the goal of this change is to make it harder to work around stack gap randomization, lack of execute bit on pages where code can be injected via data, etc by setting the return address in the overflowed buffer to a well-known address in a library rather than code injected into the stack? On a 32-bit system, this sort of change would be disastrous in terms of address space fragmentation, I would think. However, on a 64-bit system, it might be quite a bit less so. However, I'm not sure I'd implement it this way: in a 64-bit address space, we may want to do a bit more structuring of the address space and set aside a specific region for mmap's. Does it make sense to do the randomization only for mappings with the executable bit set, or implicitly set, when talking about 64-bit architectures that have a more reasonable notion of executable than i386? Were you aware that procfs has a 'map' feature that allows you to see what the practical effect of policy chnages in address space have on processes is? You might want to experiment a bit and see what the practical impact of maximum mapping is after loading a few shared libraries (etc) with this policy in place. If it turns out that, after 40 shared libraries are mapped into an address space, the process can no longer mmap more than a few megs, I'd definitely vote against it being included. Konqueror, btw, maps about 40 shared libraries by default on my notebook :-). How was the adjustment value of 256k selected, btw? Robert N M Watson