Time to disable BIND 9 custom malloc by default?

Sean Channel pentabular at gmail.com
Fri Apr 11 18:41:02 UTC 2014


+1

Truly ‘our own malloc()’ can be a necessity in many codes, but I strongly prefer the option to use the system’s own, esp. if I want to trace anything myself without understanding the code first.

I guess this was already on Evan’s mind. :) 

_S

P.S. aint’ it funny they let Weev go in the wake of Heartbleed?

On Apr 11, 2014, at 9:23 AM, Evan Hunt <each at isc.org> wrote:

> On Fri, Apr 11, 2014 at 10:52:20AM +0200, Shane Kerr wrote:
>> BIND 9 also has it's own memory handler, which is also on by default
>> IIRC. Perhaps it is time to consider disabling this?
> 
> I agree with Paul's analysis: there might be a performance benefit, but
> it isn't necessary for security; it might even be counterproductive.
> The principle advantage of BIND's isc_mem functions (from my perspective
> as a developer at any rate) is how easy they make it to diagnose and
> locate memory leaks, use-after-free conditions and the like, and the
> separation of memory contexts with individually defined limits.
> 
> One of the projects on my "when I get around to it" list is to write an
> alternate isc_mem implementation that's just a straight pass-through to the
> system malloc(), make it selectable as a configure option, and find out how
> much faster it would really be.  I don't think I'd want to make it the
> default unless the speedup was really substantial.
> 
> -- 
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers



More information about the bind-workers mailing list