On 04/12/2014 10:10 AM, Jimmy Hess wrote:
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.
There is no such memory manager. Writes can be caught that way, reads, not so much.
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.
Yes, I'm a little surprised to hear that such a heavily scrutinized security software don't use those usual suspect mechanisms to cover their butts. The flip side, though, is that you don't want to start then *counting* on those CYA mechanisms.
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.
Bologna. It's very common. There are lots and lots and lots of reasons to wrap bare system calls in wrappers. I haven't seen their wrappers in particular but it's nonsense to say that it's unusual.
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.
Depending on what you're doing, the difference can be huge. Malloc is a general purpose allocator with all of the heavyweight machinery general purpose requires. There's plenty of perfectly valid reasons to do your own memory management. Mike