[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-security
Subject:    Re: Protecting against kernel NULL-pointer derefs
From:       "Robert N. M. Watson" <rwatson () freebsd ! org>
Date:       2009-09-27 20:00:42
Message-ID: 4C92C4D0-1224-4885-98D4-629F67AC6DBB () freebsd ! org
[Download RAW message or body]


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
>

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]