From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 19:01:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AD68106568B; Sun, 27 Sep 2009 19:01:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 73D8B8FC12; Sun, 27 Sep 2009 19:01:27 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0B08046B06; Sun, 27 Sep 2009 15:01:27 -0400 (EDT) Date: Sun, 27 Sep 2009 20:01:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4ABFB5D1.4010408@elischer.org> Message-ID: References: <20090927150233.GH1495@arthur.nitro.dk> <4ABFB5D1.4010408@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, "Simon L. Nielsen" Subject: Re: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 19:01:27 -0000 On Sun, 27 Sep 2009, Julian Elischer wrote: > What they need to do now is find a fault where the offset is > 4096.. > > I wouldn't bet against it.. Oh, certainly -- this isn't a security policy, it's a vulnerability mitigation technique. It can be bypassed in the right (wrong?) circumstances, just like stack overflow protection, etc. However, it's also a potentially effective tool for limiting easier exploit paths. The kernel has a lot of 0x$smallnum failure modes, and probably significantly fewer 0x$arbitraryconstant ones, so limiting the former has benefit even if it doesn't limit the latter. To more thoroughly eliminate this type of exploit path, we'd need to move to independent kernel/user address spaces, which would increase robustness at signficant cost to performance. I think the current strategy offers some nice middle-ground benefits, and certainly makes it more tricky to exploit several reported vulnerabilities in the last year. Robert