[patch v1] malloc: add malloc_zero_aborts tunable

[Wilco Dijkstra]

Hi all,
 
>> We should really be using IFUNCs to select the entry points to the
>> malloc code.  Then this check can be part of a lightweight debug malloc
>> (along with the perturb code and other similar behaviors).  The IFUNC
>> resolvers would activate this code only if the tunables require it.
>
> Agreed. That's a great way to mitigate the performance impact.

I think it can be done without losing performance. I agree with the goal of
adding ifuncs, however it's not clear how easy it is. My colleague Dev had a
try at splitting up malloc implementation into different files/headers, but
had to give up due to the complexity of building malloc multiple times in
different ways - it is quite a mess...

The first question is whether we need to keep supporting the existing
debug/checking mallocs? I remember last time we had a malloc issue, the
debug/checking versions didn't help since they have different allocation
behaviours.

So what I want from a debug malloc is identical behaviour but with extra
checks. This should be configurable, eg. from low-cost additional checks
that find simple issues to doing full heap walks every X malloc/free calls
(or no such walks for the first Y calls to allow efficient binary search of heap
corruption). I've also mentioned adding a key to existing malloc chunks that
can easily be checked without changing block layout. We could still keep an
external debugging malloc if required, but it should only use the interfaces
that malloc provides (some changes to malloc were really complex since
the debug version relies on internal details). All this would be a major
improvement over the current debug/checking implementations.

Cheers,
Wilco