GSS memory allocation initial cut for review

[Jeffrey Altman]

On 9/29/2011 10:23 AM, Kevin Wasserman wrote:
> Thanks Jeff for taking the time to respond.  I appreciate your feedback.
> You are correct that we were imagining that a mechanism library might
> be loaded as a plugin for more than one mechglue and that would
> make it difficult for the mechanism to determine which mechglue's
> allocator to invoke.  It sounds like you would prefer that mechanisms 
> be built to target a particular mechglue.  The current problem 
> is that mechanisms have a tendency to do the following for buffers 
> they hand back to the glue:
> buffer->value = malloc(size);
> I think we all agree that has the potential to be very bad on windows.
> We just want that to change to 
> buffer->value = gssalloc_malloc(size);
> 
> If you actually need to recompile for every mechglue you want to 
> target, then you can pretty easily change gssalloc_malloc() to do 
> whatever is appropriate for that mechglue, so I don't see that what 
> we're proposing for MIT would force anyone else to do anything in 
> particular.
> 
> -Kevin Wasserman

Kevin:

Sam wrote:

"We think it will common for multiple mechglues to be used in the same
process and somewhat common in that case for the same third-party
mechanism to be loaded by multiple mechglues."

The mechglue to plug-in binding is a contract between the two parties.
What I am having a hard time understanding is how the proposal will
enforce that contract if a single mechanism is loaded as a plug-in by
multiple mechglue implementations in the same process.  I don't object
to there being a single instance of a mechanism that is shared by
multiple mechglue implementations but there does need to be a distinct
contract there.

It is not going to be acceptable for a mechanism to use to allocator
from mechglue A and a deallocator from mechglue B on a memory object.  A
mechanism that is designed to work with multiple mechglue layers at the
same time needs to track requests and manage resources based upon the
appropriate source.

At the moment there is no contract specification for mechanisms and the
assumption is that mechanisms are one instance per mechglue layer.  To
change that will require the specification of an explicit contract
binding and more than likely the addition of a mechglue context
structure to all calls to the mechanism so that the mechanism has a
method of associating resources with each mechglue.

The proposals I have heard appear to be attempting to ignore the
contract specification process by simply requiring everyone to do the
same thing and I do not believe that is acceptable.

Neither you nor Sam have publicly discussed all of the use cases that
you are looking to support.  It has been suggested to me in out-of-band
discussions with third parties that Moonshot requires that mechglue
layers themselves be mechanisms.  If this is the case, then I am
confident that the correct approach requires defining a mechglue layer
that includes a mechglue context for each call to a mechanism.  The
context would need to be allocated by the mechanism in response to a
request from a mechglue layer as part of an initialization handshake.

Such a SPI specification should be developed within the input of Kitten
even if the resulting specification is not published as an IETF RFC.

Jeffrey Altman





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110929/34bcf95c/attachment.bin