On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas <mike@mtcc.com> wrote:
Malloc doesn't write over to-be allocated memory, calloc does. Using a
Zero'ing newly allocated memory is not the desired behavior. The desired behavior is that a segmentation fault occurs, when an application breaks the rules --- so the bug is detected, instead of being hidden. The system free() can be configured to write junk bytes to the entire freed region, and malloc can be configured to align some allocations to the end of a page (Which is a default on OpenBSD), and allocate guard pages to cause a segmentation fault to occur if an attempt is made to double free() or read past the end of the allocated buffer.
wrapper is hardly unusual or controversial -- malloc can be expensive, and keeping lookaside list for, say, commonly used and fixed sized blocks is,
Use of the wrapper is both unusual and a bit controversial. The openssl devs found some neat rope, decided to tie the noose, and leave it permanently mounted around their neck, just praying some script kiddie doesn't find the other end of the rope and tie it to something.
at least used to be, a big performance win.
A very small possible performance win, with an extreme potential decrease in safety.
Far from getting rid of evul wrappers, it seems to me that if they were smart with their wrappers they'd have wrapper routine for anything vaguely associated with wire output that zeros the allocated memory.
This doesn't help with reading beyond the allocated memory. Of course........ if they correctly implement the same security mitigations that are available from the malloc() library that the system admin chose to install and link the application against, then there would have been no security complaint.
Mike -- -JH