[170914] in North American Network Operators' Group
Re: DNSSEC?
daemon@ATHENA.MIT.EDU (Michael Thomas)
Sat Apr 12 14:44:23 2014
Date: Sat, 12 Apr 2014 11:43:47 -0700
From: Michael Thomas <mike@mtcc.com>
To: Jimmy Hess <mysidia@gmail.com>
In-Reply-To: <CAAAwwbU95kjACpx1sNeopVw=81kWcniL01xuMFVw2bD06DUUOQ@mail.gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
