[17232] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Wed Sep 28 17:47:22 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4E8395E1.8080402@secure-endpoints.com>
Date: Wed, 28 Sep 2011 17:47:13 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <1317239459-13699-1-git-send-email-hartmans@painless-security.com>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1655497279=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1655497279==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigC1609D4909B073B63AF467DC"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC1609D4909B073B63AF467DC
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 9/28/2011 3:50 PM, Sam Hartman wrote:
>=20
> 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.)
I agree with the problem description.
> 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.
>=20
> 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 qu=
estion for kitten and I'll eventually get around to bringing it up there.=
I do not believe that it is acceptable to require that all GSS mechglue
layers on a given platform use the same allocator. I agree that it will
be common for multiple mechglue layers to be present in a given process.
The obvious example is IIS which can load hundreds of independently
developed application modules each of which might be developed against
an independently developed GSS stack. The reason that Asanka and I
have pushed for the use of side-by-side assemblies on Windows is to
permit the deployment of independent GSS and Kerberos stacks within an
application to become a possibility.
Adding a requirement that all GSS stacks and all mechglue layers and all
GSS mechanisms use a system-wide allocator will certainly address the
problem but at a significant cost to the freedom of GSS stack
developers. By requiring that a particular allocator be used, you are
ruling about the ability to use custom allocators for memory debugging
or any other purpose.
For starters, I'm not sure I agree that it should be considered safe for
a single instance of a mechanism to be shared across multiple mechglue
implementations since at present there is no standardized mechglue
interface across all implementations. The mechglue interface is a
contract between the mechglue provider and the underlying mechanisms.
There is no guarantee that this contract is the same across all mechglue
implementations nor do I believe that there is a need for there to be.
Perhaps I am misunderstanding you but it sounds like what you want is a
mechanism to be loaded as a plug-in to both MIT X and Heimdal Y and for
that mechanism to be able to use the allocator it obtained from MIT X
when allocating buffers to be used by Heimdal Y. If so, I think this is
a recipe for disaster.
If you are attempting to solve a different problem, I would appreciate
it if you could attempt to explain it a second time with a bit more
detail related to the flow of buffer allocation and deallocation within
the process.
Thank you.
Jeffrey Altman
--------------enigC1609D4909B073B63AF467DC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJOg5XiAAoJENxm1CNJffh49bAIAKbCTRbnEtf8UKKkWFBLQaFQ
DwaAosnaKELla9Adup4MHNX5N+zjr0H0AtovIQ9aL7BlMa/DDv5OyGZzJv0kgsDD
D2XmpmA6GsfI/jLYusH48gApWFm6TpnC45o/6IPEy3pf8XomHaWwdEdZ3KlAanmR
fZtj9+GfqYGCF2PeE17Kb+ZfMvuZeEwyNFUkfmRoe3LaKxlBzemI0oPz1MNPvj1k
VtN2RBFP+wFDvqMyjEzZFQEKbp5ZtMHuDkxb+MYD587Z1E62aTPD0JCFqEXL7hA/
ycuxiou8MRTj2unENmtDNK2w+uiTxvZm0otXW2R//MowLZYWV1wMONzidELItYE=
=dawl
-----END PGP SIGNATURE-----
--------------enigC1609D4909B073B63AF467DC--
--===============1655497279==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1655497279==--
