[17235] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Thu Sep 29 11:21:02 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4E848CD1.9080101@secure-endpoints.com>
Date: Thu, 29 Sep 2011 11:20:49 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <SNT101-DS25402C68BA343D5D122654B5F60@phx.gbl>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============0962170609=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0962170609==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigFDF7B9111FE91C7C61D7754A"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFDF7B9111FE91C7C61D7754A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 9/29/2011 10:23 AM, Kevin Wasserman wrote:
> Thanks Jeff for taking the time to respond. I appreciate your feedback=
=2E
> 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=20
> be built to target a particular mechglue. The current problem=20
> is that mechanisms have a tendency to do the following for buffers=20
> they hand back to the glue:
> buffer->value =3D malloc(size);
> I think we all agree that has the potential to be very bad on windows.
> We just want that to change to=20
> buffer->value =3D gssalloc_malloc(size);
>=20
> If you actually need to recompile for every mechglue you want to=20
> target, then you can pretty easily change gssalloc_malloc() to do=20
> whatever is appropriate for that mechglue, so I don't see that what=20
> we're proposing for MIT would force anyone else to do anything in=20
> particular.
>=20
> -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
--------------enigFDF7B9111FE91C7C61D7754A
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)
iQEcBAEBAgAGBQJOhIzTAAoJENxm1CNJffh4BmUIAKkv58O2RbiKh9rvMziy/rsT
0DWiIWUMJC0l7H1BuiQHUv2Ukc5aFIzl4w1zGHGUbmTOB0UXOlpJN8i3ByRC2Xz9
p4iH7PFtUX5E3sQuBEFSTYwwNUA7ceWynUthDPErlGH5OUJZwApJ+cI6v+EB4P2P
t1dxVVfmcrZpi9HFqnbNBtopSXl7yEKDXHZ+VybIVpM6QfnkcefiWU5VHx+HSQQZ
34tWlNLz9zdFoMFSsSmn44u8zsE0UqNfLQAb372b/UcptUCroDw1gQ3MXsg77QUb
kC3DWBlyblkZQDtREAJ5tDO/tfrPydTG4WJbeiCvMSpW+gX86D8vhR29KCL8sXs=
=xIN6
-----END PGP SIGNATURE-----
--------------enigFDF7B9111FE91C7C61D7754A--
--===============0962170609==
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
--===============0962170609==--
