DNSSEC?

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 
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



More information about the NANOG mailing list