GSS memory allocation initial cut for review

Kevin Wasserman krwasserman at hotmail.com
Wed Sep 28 16:59:47 EDT 2011


Thanks Sam for sending out that write-up and those patches.

I was finally able to convince git to allow me to rebase and
squash that WIP patch into a later commit; the attached set
of three patches should be a bit more readable.
Also, apologies for the giant _WIN32 error message
block in gss-misc.c; I didn't really intend that to be part of
this commit.

-Kevin Wasserman

-----Original Message----- 
From: Sam Hartman
Sent: Wednesday, September 28, 2011 3:50 PM
To: krbdev at mit.edu
Cc: kevin.wasserman at painless-security.com
Subject: GSS memory allocation initial cut for review


Hi.  One of the problems with using GSS-API mechanism plugins on
Windows is that the malloc provided by the C runtime requires that you
free allocations in the same dll as you allocate them.  (It's more
complicated than that, but if you follow that rule it works.)

This means that if you allocate a buffer in a mechanism, that
mechanism needs to release it.  That makes implementing
gss_release_buffer difficult.  In theory you could copy buffers in the
mechglue, or register pointers in the mechglue.

We're proposing an alternative. We're proposing that on a given
platform we use a well defined allocator for GSS mechglues and
mechanisms.  We don't think it is sufficient for a mechglue layer to
export an allocator for mechanisms to use. 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.  So, we actually think we need to standardize on
an allocation strategy.
The question of whether we need a platform-global GSS allocator is a 
question for kitten and I'll eventually get around to bringing it up there.

However, a lot of this is MIT-specific. In particular, the code
changes to move all buffer allocations through one allocator and free
function are MIT specific. Also, our choice of allocator for the
Windows platform is MIT-specific up until the point that kitten
chooses something else.

I'd appreciate review of this first initial patch set now.

Assuming our claim about multiple mechglues is right, patches are also
required for buffer sets and oid sets.

Thanks,

--Sam 


More information about the krbdev mailing list