[17247] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Oct 4 12:43:09 2011
MIME-Version: 1.0
In-Reply-To: <SNT101-DS16AC10DCD815C563AFAA65B5FB0@phx.gbl>
Date: Tue, 4 Oct 2011 11:43:03 -0500
Message-ID: <CAK3OfOg7eoxBDxgdYr8FQFJx387+R9FN=ob1SWmYxgo4=70WzQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Kevin Wasserman <krwasserman@hotmail.com>
Cc: Sam Hartman <hartmans@painless-security.com>,
kevin.wasserman@painless-security.com, krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Oct 4, 2011 at 5:34 AM, Kevin Wasserman <krwasserman@hotmail.com> wrote:> We could pick a registry key that, if present, specifies the dll and> malloc/free functions to use and only fall back to HeapAlloc if it's not> set. Then the question becomes,> when do we check the registry key? On every alloc/free?> On process init?
I would think on process init, otherwise you'd risk freeing memorywith the wrong allocator.
There are other less invasive solutions, such as having the mechgluetrack all the buffers returned by providers and then looking up eachbuffer address to find which provider's release_buffer entry point tocall. This is something I've wished to avoid, but Windows makes mesad enough about the common allocator approach that I'd consider it.Let's see what Jeff says about the configurable GSS allocator DLL idea-- that'd be the least disruptive approach for you at this point,after all.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
