Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Sep 2009 21:00:42 +0100
From:      "Robert N. M. Watson" <rwatson@freebsd.org>
To:        Brett Glass <brett@lariat.net>
Cc:        freebsd-security@freebsd.org, Pieter de Boer <pieter@thedarkside.nl>
Subject:   Re: Protecting against kernel NULL-pointer derefs
Message-ID:  <4C92C4D0-1224-4885-98D4-629F67AC6DBB@freebsd.org>
In-Reply-To: <200909271904.NAA14681@lariat.net>
References:  <4AAF4A64.3080906@thedarkside.nl> <alpine.BSF.2.00.0909271937490.41451@fledge.watson.org> <200909271904.NAA14681@lariat.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C92C4D0-1224-4885-98D4-629F67AC6DBB>