From owner-freebsd-security@FreeBSD.ORG Sun Sep 27 20:00:45 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF379106566C for ; Sun, 27 Sep 2009 20:00:45 +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 B7B3A8FC16 for ; Sun, 27 Sep 2009 20:00:45 +0000 (UTC) Received: from [192.168.2.101] (host81-155-13-237.range81-155.btcentralplus.com [81.155.13.237]) by cyrus.watson.org (Postfix) with ESMTPSA id 6F25746B0C; Sun, 27 Sep 2009 16:00:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: <200909271904.NAA14681@lariat.net> Date: Sun, 27 Sep 2009 21:00:42 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4C92C4D0-1224-4885-98D4-629F67AC6DBB@freebsd.org> References: <4AAF4A64.3080906@thedarkside.nl> <200909271904.NAA14681@lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1075.2) Cc: freebsd-security@freebsd.org, Pieter de Boer Subject: Re: Protecting against kernel NULL-pointer derefs X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 20:00:46 -0000 On 27 Sep 2009, at 20:04, Brett Glass wrote: > As someone who has been frustrated by a disproportionate number of > bugs related to null and wild pointer dereferencing, I'd opt for > such an option to be incorporated in the next point release. > > Perhaps, there could be two options: one to generate a warning in > the log and then "fail soft" (e.g. by mapping a zero page) and > another to cause a hard panic. The "fail soft" option would be > particularly handy to help flush out bugs -- particularly in device > drivers -- in preparation for making a hard panic the default at > some future time. It would also provide a fallback for > administrators, to allow them to keep their systems running while a > bug was diagnosed and fixed. Right now the immediate goals are: (1) Enable by default in head so that we can evaluate the compatibility fallout (2) Provide the ability to enable on other -stable and -security branches non-default My guess is that we'll enable it in -stable (and hence point releases) fairly quickly, but it's not a switch we want to throw in -stable until we have a better understanding of the impact. We're also still working through the implementation details so I suspect more commits will follow. In practice, it will be tools like "doscmd" that fail in the new world order; some may not consider this a significant functional loss. We observe that Wine does do a mapping at NULL by default, but seems not to mind if it can't (as is also true on Linux I believe). Robert > > --Brett Glass > > At 12:39 PM 9/27/2009, Robert Watson wrote: > >> FYI, changes are now going into head to implement this policy, >> although by slightly different mechanisms. I expect to see them >> merged to various branches, and also to active security branches >> (although disabled there by default using a sysctl so as not to >> disturb existing setups unless desired by the administrator). >> >> Robert >