On 04/12/2014 10:10 AM, Jimmy Hess wrote:
On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas <m...@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
