living in a multi-mech world

[Nicolas Williams]

On Sun, Apr 29, 2007 at 11:00:54PM -0600, Philip Guenther wrote:
> On 4/29/07, Tom Yu <tlyu at mit.edu> wrote:
> > gss_buffer_desc doesn't have any way to identify which mechanism may
> > have allocated the memory to which it points.  In a multi-mechanism
> > implementation, this means either forcing all mechanisms to use the
> > same memory allocator (intractable in various situations, including
> > Windows DLLs, from what I understand) or somehow registering which
> > memory blocks belong to which mechanisms so that mechglue can call the
> > correct gss_release_buffer().
> 
> While forcing all mechs to use the same allocator may be intractable,
> doing all the 'exported' allocation with the allocator from the SPI
> may not be.  In an unrelated project using dynamicly loaded modules,
> the plugin's functions all were given an extra argument that was a
> pointer to a structure of callbacks including memory allocation and
> release, a logging call, and a "look up config file entry" call.  The
> plugins then used those callbacks for stuff crossing the
> application<->plugin boundary, but plain malloc()/free() for stuff
> local to the plugin.

There's no need to do that if you can rely on the RTLD.  If you can't
then add an initialization function that gets these function pointers as
input and saves them in static globals -- no need to add an argument to
every SPI function.

> The downside of that, of course, is that it may require copying data
> between buffers in the mech's own SPI glue if the underlying mech
> implementation is less flexible about how buffers are managed.  That
> wasn't an issue in the project I'm thinking of, but it may be a
> concern here.

It certainly would be here for apps that move bulk data (gratuitous data
copies do hurt, even when you're doing crypto).

> Note that since these callbacks are provided as a structure of
> pointers and not as exported symbols, there's no concerns about symbol
> conflicts or overrides with multiple loads of the mech-glue layer.

There's no such concerns when you use dlsym() wth a handle obtained from
dlopen() either.  There are such concerns when relying on dynamic
linking without using dlopen()/dlsym().

> If SPNEGO is built on the internal SPI (i.e., the "get direct access
> to a specific mech" call) instead of trying to reinvoke the plain
> GSS-API calls, then it could actually pass through the callback
> structure that _it_ received down to the mech that it's invoking,
> possibly avoiding buffer copying pain.

Pseudo-mechs shouldn't get direct access to other mechs -- they should
always re-enter the mechglue (recursion ends because the various input
parameters refer to other mechanisms -- as long as the pseudo-mechanism
itself is not infinitely recursive).

Re-entering the mechglue from pseudo-mechanisms should add some
overhead (extra frames on the stack), but not data copies.

Nico
--