Michael Thomas mike at mtcc.com
Sat Apr 12 18:43:47 UTC 2014

On 04/12/2014 10:10 AM, Jimmy Hess wrote:
> On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas <mike at 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 
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 
purpose allocator with all of the heavyweight machinery general purpose 
There's plenty of perfectly valid reasons to do your own memory management.


More information about the NANOG mailing list