From owner-freebsd-current@FreeBSD.ORG Sun Sep 27 18:58:23 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 156CE106566B for ; Sun, 27 Sep 2009 18:58:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id F05C68FC18 for ; Sun, 27 Sep 2009 18:58:22 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7EB71CEA2E; Sun, 27 Sep 2009 11:58:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4233B2D6013; Sun, 27 Sep 2009 11:58:22 -0700 (PDT) Message-ID: <4ABFB5D1.4010408@elischer.org> Date: Sun, 27 Sep 2009 11:58:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Robert Watson References: <20090927150233.GH1495@arthur.nitro.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 18:58:23 -0000 Robert Watson wrote: > > On Sun, 27 Sep 2009, Simon L. Nielsen wrote: > >> As mentioned in the commit message FreeBSD 9 / head now does not allow >> mmap'ing at zero by default, and this may break some apps. >> >> If anyone encounters applications which break because of this change, >> please let report it so we can see if it can be fixed. It might not >> be possible to fix some applications, but we at least would know which >> applications might need a special note in the documentation. > > There are probably some other ways to arrange mappings at 0x0, so we'll > need to dig through the system to identify them. To mind, the various > executable image activators are interesting (elf, a.out, etc), but we > should check other things that call VM insertion routines -- things like > the more interesting 3D device drivers. At the end of the day, this is > a mitigation technique, so if there are edge case non-default compiled > copmonents, etc, that's fine, but it would be nice to be thorough where > we can. > > While our automatic address selection code ever pick 0x0 as a mapping > address, btw? > > Robert N M Watson > Computer Laboratory > University of Cambridge > > >> What they need to do now is find a fault where the offset is > 4096.. I wouldn't bet against it..