1998-12-21 18:56:39 +08:00
|
|
|
/* crypto/ex_data.c */
|
2000-12-16 00:40:35 +08:00
|
|
|
|
|
|
|
|
/*
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
* Overhaul notes;
|
2000-12-16 00:40:35 +08:00
|
|
|
*
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
* This code is now *mostly* thread-safe. It is now easier to understand in what
|
|
|
|
|
* ways it is safe and in what ways it is not, which is an improvement. Firstly,
|
|
|
|
|
* all per-class stacks and index-counters for ex_data are stored in the same
|
|
|
|
|
* global LHASH table (keyed by class). This hash table uses locking for all
|
|
|
|
|
* access with the exception of CRYPTO_cleanup_all_ex_data(), which must only be
|
|
|
|
|
* called when no other threads can possibly race against it (even if it was
|
|
|
|
|
* locked, the race would mean it's possible the hash table might have been
|
|
|
|
|
* recreated after the cleanup). As classes can only be added to the hash table,
|
|
|
|
|
* and within each class, the stack of methods can only be incremented, the
|
|
|
|
|
* locking mechanics are simpler than they would otherwise be. For example, the
|
|
|
|
|
* new/dup/free ex_data functions will lock the hash table, copy the method
|
|
|
|
|
* pointers it needs from the relevant class, then unlock the hash table before
|
|
|
|
|
* actually applying those method pointers to the task of the new/dup/free
|
|
|
|
|
* operations. As they can't be removed from the method-stack, only
|
|
|
|
|
* supplemented, there's no race conditions associated with using them outside
|
|
|
|
|
* the lock. The get/set_ex_data functions are not locked because they do not
|
|
|
|
|
* involve this global state at all - they operate directly with a previously
|
|
|
|
|
* obtained per-class method index and a particular "ex_data" variable. These
|
|
|
|
|
* variables are usually instantiated per-context (eg. each RSA structure has
|
|
|
|
|
* one) so locking on read/write access to that variable can be locked locally
|
|
|
|
|
* if required (eg. using the "RSA" lock to synchronise access to a
|
|
|
|
|
* per-RSA-structure ex_data variable if required).
|
|
|
|
|
* [Geoff]
|
2000-12-16 00:40:35 +08:00
|
|
|
*/
|
|
|
|
|
|
1998-12-21 18:56:39 +08:00
|
|
|
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* This package is an SSL implementation written
|
|
|
|
|
* by Eric Young (eay@cryptsoft.com).
|
|
|
|
|
* The implementation was written so as to conform with Netscapes SSL.
|
|
|
|
|
*
|
|
|
|
|
* This library is free for commercial and non-commercial use as long as
|
|
|
|
|
* the following conditions are aheared to. The following conditions
|
|
|
|
|
* apply to all code found in this distribution, be it the RC4, RSA,
|
|
|
|
|
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
|
|
|
|
|
* included with this distribution is covered by the same copyright terms
|
|
|
|
|
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
|
|
|
|
|
*
|
|
|
|
|
* Copyright remains Eric Young's, and as such any Copyright notices in
|
|
|
|
|
* the code are not to be removed.
|
|
|
|
|
* If this package is used in a product, Eric Young should be given attribution
|
|
|
|
|
* as the author of the parts of the library used.
|
|
|
|
|
* This can be in the form of a textual message at program startup or
|
|
|
|
|
* in documentation (online or textual) provided with the package.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
|
* "This product includes cryptographic software written by
|
|
|
|
|
* Eric Young (eay@cryptsoft.com)"
|
|
|
|
|
* The word 'cryptographic' can be left out if the rouines from the library
|
|
|
|
|
* being used are not cryptographic related :-).
|
|
|
|
|
* 4. If you include any Windows specific code (or a derivative thereof) from
|
|
|
|
|
* the apps directory (application code) you must include an acknowledgement:
|
|
|
|
|
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* The licence and distribution terms for any publically available version or
|
|
|
|
|
* derivative of this code cannot be changed. i.e. this code cannot simply be
|
|
|
|
|
* copied and put under another distribution licence
|
|
|
|
|
* [including the GNU Public Licence.]
|
|
|
|
|
*/
|
2001-09-04 19:02:23 +08:00
|
|
|
/* ====================================================================
|
|
|
|
|
* Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
*
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
*
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
|
* distribution.
|
|
|
|
|
*
|
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
|
|
|
|
|
*
|
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
|
* openssl-core@openssl.org.
|
|
|
|
|
*
|
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
|
*
|
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
|
* acknowledgment:
|
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
* ====================================================================
|
|
|
|
|
*
|
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
|
* Hudson (tjh@cryptsoft.com).
|
|
|
|
|
*
|
|
|
|
|
*/
|
1998-12-21 18:56:39 +08:00
|
|
|
|
|
|
|
|
#include "cryptlib.h"
|
2004-04-20 02:09:28 +08:00
|
|
|
#include <openssl/lhash.h>
|
1998-12-21 18:56:39 +08:00
|
|
|
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
/* What an "implementation of ex_data functionality" looks like */
|
|
|
|
|
struct st_CRYPTO_EX_DATA_IMPL
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
/*********************/
|
|
|
|
|
/* GLOBAL OPERATIONS */
|
|
|
|
|
/* Return a new class index */
|
|
|
|
|
int (*cb_new_class)(void);
|
|
|
|
|
/* Cleanup all state used by the implementation */
|
|
|
|
|
void (*cb_cleanup)(void);
|
|
|
|
|
/************************/
|
|
|
|
|
/* PER-CLASS OPERATIONS */
|
|
|
|
|
/* Get a new method index within a class */
|
|
|
|
|
int (*cb_get_new_index)(int class_index, long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
|
|
|
|
|
CRYPTO_EX_free *free_func);
|
|
|
|
|
/* Initialise a new CRYPTO_EX_DATA of a given class */
|
|
|
|
|
int (*cb_new_ex_data)(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad);
|
|
|
|
|
/* Duplicate a CRYPTO_EX_DATA of a given class onto a copy */
|
|
|
|
|
int (*cb_dup_ex_data)(int class_index, CRYPTO_EX_DATA *to,
|
|
|
|
|
CRYPTO_EX_DATA *from);
|
|
|
|
|
/* Cleanup a CRYPTO_EX_DATA of a given class */
|
|
|
|
|
void (*cb_free_ex_data)(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad);
|
|
|
|
|
};
|
1998-12-21 18:56:39 +08:00
|
|
|
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
/* The implementation we use at run-time */
|
|
|
|
|
static const CRYPTO_EX_DATA_IMPL *impl = NULL;
|
|
|
|
|
|
|
|
|
|
/* To call "impl" functions, use this macro rather than referring to 'impl' directly, eg.
|
|
|
|
|
* EX_IMPL(get_new_index)(...); */
|
|
|
|
|
#define EX_IMPL(a) impl->cb_##a
|
|
|
|
|
|
|
|
|
|
/* Predeclare the "default" ex_data implementation */
|
|
|
|
|
static int int_new_class(void);
|
|
|
|
|
static void int_cleanup(void);
|
|
|
|
|
static int int_get_new_index(int class_index, long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
|
|
|
|
|
CRYPTO_EX_free *free_func);
|
|
|
|
|
static int int_new_ex_data(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad);
|
|
|
|
|
static int int_dup_ex_data(int class_index, CRYPTO_EX_DATA *to,
|
|
|
|
|
CRYPTO_EX_DATA *from);
|
|
|
|
|
static void int_free_ex_data(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad);
|
|
|
|
|
static CRYPTO_EX_DATA_IMPL impl_default =
|
|
|
|
|
{
|
|
|
|
|
int_new_class,
|
|
|
|
|
int_cleanup,
|
|
|
|
|
int_get_new_index,
|
|
|
|
|
int_new_ex_data,
|
|
|
|
|
int_dup_ex_data,
|
|
|
|
|
int_free_ex_data
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Internal function that checks whether "impl" is set and if not, sets it to
|
|
|
|
|
* the default. */
|
|
|
|
|
static void impl_check(void)
|
|
|
|
|
{
|
|
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
if(!impl)
|
|
|
|
|
impl = &impl_default;
|
|
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
}
|
|
|
|
|
/* A macro wrapper for impl_check that first uses a non-locked test before
|
|
|
|
|
* invoking the function (which checks again inside a lock). */
|
|
|
|
|
#define IMPL_CHECK if(!impl) impl_check();
|
|
|
|
|
|
|
|
|
|
/* API functions to get/set the "ex_data" implementation */
|
|
|
|
|
const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
|
|
|
|
return impl;
|
|
|
|
|
}
|
|
|
|
|
int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i)
|
|
|
|
|
{
|
|
|
|
|
int toret = 0;
|
|
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
if(!impl)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
impl = i;
|
|
|
|
|
toret = 1;
|
1998-12-21 18:56:39 +08:00
|
|
|
}
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
|
/* Interal (default) implementation of "ex_data" support. API functions are
|
|
|
|
|
* further down. */
|
|
|
|
|
|
|
|
|
|
/* The type that represents what each "class" used to implement locally. A STACK
|
|
|
|
|
* of CRYPTO_EX_DATA_FUNCS plus a index-counter. The 'class_index' is the global
|
|
|
|
|
* value representing the class that is used to distinguish these items. */
|
|
|
|
|
typedef struct st_ex_class_item {
|
|
|
|
|
int class_index;
|
|
|
|
|
STACK_OF(CRYPTO_EX_DATA_FUNCS) *meth;
|
|
|
|
|
int meth_num;
|
|
|
|
|
} EX_CLASS_ITEM;
|
|
|
|
|
|
|
|
|
|
/* When assigning new class indexes, this is our counter */
|
|
|
|
|
static int ex_class = CRYPTO_EX_INDEX_USER;
|
|
|
|
|
|
|
|
|
|
/* The global hash table of EX_CLASS_ITEM items */
|
2008-05-26 19:24:29 +08:00
|
|
|
DECLARE_LHASH_OF(EX_CLASS_ITEM);
|
|
|
|
|
static LHASH_OF(EX_CLASS_ITEM) *ex_data = NULL;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
|
|
|
|
|
/* The callbacks required in the "ex_data" hash table */
|
2008-05-26 19:24:29 +08:00
|
|
|
static unsigned long ex_class_item_hash(const EX_CLASS_ITEM *a)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2008-05-26 19:24:29 +08:00
|
|
|
return a->class_index;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
}
|
2008-06-01 03:17:25 +08:00
|
|
|
static IMPLEMENT_LHASH_HASH_FN(ex_class_item, EX_CLASS_ITEM)
|
2008-05-26 19:24:29 +08:00
|
|
|
|
|
|
|
|
static int ex_class_item_cmp(const EX_CLASS_ITEM *a, const EX_CLASS_ITEM *b)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2008-05-26 19:24:29 +08:00
|
|
|
return a->class_index - b->class_index;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
}
|
2008-06-01 03:17:25 +08:00
|
|
|
static IMPLEMENT_LHASH_COMP_FN(ex_class_item, EX_CLASS_ITEM)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
|
|
|
|
|
/* Internal functions used by the "impl_default" implementation to access the
|
|
|
|
|
* state */
|
|
|
|
|
|
|
|
|
|
static int ex_data_check(void)
|
|
|
|
|
{
|
|
|
|
|
int toret = 1;
|
|
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
2008-05-26 19:24:29 +08:00
|
|
|
if(!ex_data
|
|
|
|
|
&& (ex_data = lh_EX_CLASS_ITEM_new()) == NULL)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
toret = 0;
|
|
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
/* This macros helps reduce the locking from repeated checks because the
|
|
|
|
|
* ex_data_check() function checks ex_data again inside a lock. */
|
|
|
|
|
#define EX_DATA_CHECK(iffail) if(!ex_data && !ex_data_check()) {iffail}
|
|
|
|
|
|
|
|
|
|
/* This "inner" callback is used by the callback function that follows it */
|
2001-09-07 19:43:30 +08:00
|
|
|
static void def_cleanup_util_cb(CRYPTO_EX_DATA_FUNCS *funcs)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
OPENSSL_free(funcs);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This callback is used in lh_doall to destroy all EX_CLASS_ITEM values from
|
|
|
|
|
* "ex_data" prior to the ex_data hash table being itself destroyed. Doesn't do
|
|
|
|
|
* any locking. */
|
2003-10-29 12:57:05 +08:00
|
|
|
static void def_cleanup_cb(void *a_void)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
EX_CLASS_ITEM *item = (EX_CLASS_ITEM *)a_void;
|
|
|
|
|
sk_CRYPTO_EX_DATA_FUNCS_pop_free(item->meth, def_cleanup_util_cb);
|
|
|
|
|
OPENSSL_free(item);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Return the EX_CLASS_ITEM from the "ex_data" hash table that corresponds to a
|
|
|
|
|
* given class. Handles locking. */
|
|
|
|
|
static EX_CLASS_ITEM *def_get_class(int class_index)
|
|
|
|
|
{
|
|
|
|
|
EX_CLASS_ITEM d, *p, *gen;
|
|
|
|
|
EX_DATA_CHECK(return NULL;)
|
|
|
|
|
d.class_index = class_index;
|
|
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
2008-05-26 19:24:29 +08:00
|
|
|
p = lh_EX_CLASS_ITEM_retrieve(ex_data, &d);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
if(!p)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
gen = OPENSSL_malloc(sizeof(EX_CLASS_ITEM));
|
|
|
|
|
if(gen)
|
|
|
|
|
{
|
|
|
|
|
gen->class_index = class_index;
|
|
|
|
|
gen->meth_num = 0;
|
|
|
|
|
gen->meth = sk_CRYPTO_EX_DATA_FUNCS_new_null();
|
|
|
|
|
if(!gen->meth)
|
|
|
|
|
OPENSSL_free(gen);
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* Because we're inside the ex_data lock, the
|
|
|
|
|
* return value from the insert will be NULL */
|
2008-07-05 07:12:52 +08:00
|
|
|
(void)lh_EX_CLASS_ITEM_insert(ex_data, gen);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
p = gen;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
if(!p)
|
|
|
|
|
CRYPTOerr(CRYPTO_F_DEF_GET_CLASS,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return p;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add a new method to the given EX_CLASS_ITEM and return the corresponding
|
|
|
|
|
* index (or -1 for error). Handles locking. */
|
|
|
|
|
static int def_add_index(EX_CLASS_ITEM *item, long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
|
|
|
|
|
CRYPTO_EX_free *free_func)
|
|
|
|
|
{
|
|
|
|
|
int toret = -1;
|
|
|
|
|
CRYPTO_EX_DATA_FUNCS *a = (CRYPTO_EX_DATA_FUNCS *)OPENSSL_malloc(
|
|
|
|
|
sizeof(CRYPTO_EX_DATA_FUNCS));
|
|
|
|
|
if(!a)
|
|
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_DEF_ADD_INDEX,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return -1;
|
1998-12-21 18:56:39 +08:00
|
|
|
}
|
|
|
|
|
a->argl=argl;
|
|
|
|
|
a->argp=argp;
|
|
|
|
|
a->new_func=new_func;
|
|
|
|
|
a->dup_func=dup_func;
|
|
|
|
|
a->free_func=free_func;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
while (sk_CRYPTO_EX_DATA_FUNCS_num(item->meth) <= item->meth_num)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
if (!sk_CRYPTO_EX_DATA_FUNCS_push(item->meth, NULL))
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
CRYPTOerr(CRYPTO_F_DEF_ADD_INDEX,ERR_R_MALLOC_FAILURE);
|
2000-06-02 06:19:21 +08:00
|
|
|
OPENSSL_free(a);
|
1998-12-21 19:00:56 +08:00
|
|
|
goto err;
|
1998-12-21 18:56:39 +08:00
|
|
|
}
|
|
|
|
|
}
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
toret = item->meth_num++;
|
2008-02-28 22:05:01 +08:00
|
|
|
(void)sk_CRYPTO_EX_DATA_FUNCS_set(item->meth, toret, a);
|
1998-12-21 19:00:56 +08:00
|
|
|
err:
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**************************************************************/
|
|
|
|
|
/* The functions in the default CRYPTO_EX_DATA_IMPL structure */
|
|
|
|
|
|
|
|
|
|
static int int_new_class(void)
|
|
|
|
|
{
|
|
|
|
|
int toret;
|
|
|
|
|
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
toret = ex_class++;
|
|
|
|
|
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
|
|
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void int_cleanup(void)
|
|
|
|
|
{
|
|
|
|
|
EX_DATA_CHECK(return;)
|
2008-05-26 19:24:29 +08:00
|
|
|
lh_EX_CLASS_ITEM_doall(ex_data, def_cleanup_cb);
|
|
|
|
|
lh_EX_CLASS_ITEM_free(ex_data);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
ex_data = NULL;
|
|
|
|
|
impl = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int int_get_new_index(int class_index, long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
|
|
|
|
|
CRYPTO_EX_free *free_func)
|
|
|
|
|
{
|
|
|
|
|
EX_CLASS_ITEM *item = def_get_class(class_index);
|
|
|
|
|
if(!item)
|
|
|
|
|
return -1;
|
|
|
|
|
return def_add_index(item, argl, argp, new_func, dup_func, free_func);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Thread-safe by copying a class's array of "CRYPTO_EX_DATA_FUNCS" entries in
|
|
|
|
|
* the lock, then using them outside the lock. NB: Thread-safety only applies to
|
|
|
|
|
* the global "ex_data" state (ie. class definitions), not thread-safe on 'ad'
|
|
|
|
|
* itself. */
|
|
|
|
|
static int int_new_ex_data(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad)
|
|
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
int mx,i;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
void *ptr;
|
|
|
|
|
CRYPTO_EX_DATA_FUNCS **storage = NULL;
|
|
|
|
|
EX_CLASS_ITEM *item = def_get_class(class_index);
|
|
|
|
|
if(!item)
|
|
|
|
|
/* error is already set */
|
|
|
|
|
return 0;
|
|
|
|
|
ad->sk = NULL;
|
|
|
|
|
CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth);
|
|
|
|
|
if(mx > 0)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
storage = OPENSSL_malloc(mx * sizeof(CRYPTO_EX_DATA_FUNCS*));
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
if(!storage)
|
|
|
|
|
goto skip;
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
storage[i] = sk_CRYPTO_EX_DATA_FUNCS_value(item->meth,i);
|
|
|
|
|
}
|
|
|
|
|
skip:
|
|
|
|
|
CRYPTO_r_unlock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
if((mx > 0) && !storage)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_INT_NEW_EX_DATA,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
if(storage[i] && storage[i]->new_func)
|
|
|
|
|
{
|
|
|
|
|
ptr = CRYPTO_get_ex_data(ad, i);
|
|
|
|
|
storage[i]->new_func(obj,ptr,ad,i,
|
|
|
|
|
storage[i]->argl,storage[i]->argp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if(storage)
|
|
|
|
|
OPENSSL_free(storage);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same thread-safety notes as for "int_new_ex_data" */
|
|
|
|
|
static int int_dup_ex_data(int class_index, CRYPTO_EX_DATA *to,
|
|
|
|
|
CRYPTO_EX_DATA *from)
|
|
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
int mx, j, i;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
char *ptr;
|
|
|
|
|
CRYPTO_EX_DATA_FUNCS **storage = NULL;
|
|
|
|
|
EX_CLASS_ITEM *item;
|
|
|
|
|
if(!from->sk)
|
|
|
|
|
/* 'to' should be "blank" which *is* just like 'from' */
|
|
|
|
|
return 1;
|
|
|
|
|
if((item = def_get_class(class_index)) == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth);
|
2008-06-04 19:01:43 +08:00
|
|
|
j = sk_void_num(from->sk);
|
2001-09-03 04:41:34 +08:00
|
|
|
if(j < mx)
|
|
|
|
|
mx = j;
|
|
|
|
|
if(mx > 0)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
storage = OPENSSL_malloc(mx * sizeof(CRYPTO_EX_DATA_FUNCS*));
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
if(!storage)
|
|
|
|
|
goto skip;
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
storage[i] = sk_CRYPTO_EX_DATA_FUNCS_value(item->meth,i);
|
|
|
|
|
}
|
|
|
|
|
skip:
|
|
|
|
|
CRYPTO_r_unlock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
if((mx > 0) && !storage)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_INT_DUP_EX_DATA,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
ptr = CRYPTO_get_ex_data(from, i);
|
|
|
|
|
if(storage[i] && storage[i]->dup_func)
|
|
|
|
|
storage[i]->dup_func(to,from,&ptr,i,
|
|
|
|
|
storage[i]->argl,storage[i]->argp);
|
|
|
|
|
CRYPTO_set_ex_data(to,i,ptr);
|
|
|
|
|
}
|
|
|
|
|
if(storage)
|
|
|
|
|
OPENSSL_free(storage);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same thread-safety notes as for "int_new_ex_data" */
|
|
|
|
|
static void int_free_ex_data(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad)
|
|
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
int mx,i;
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
EX_CLASS_ITEM *item;
|
|
|
|
|
void *ptr;
|
|
|
|
|
CRYPTO_EX_DATA_FUNCS **storage = NULL;
|
|
|
|
|
if((item = def_get_class(class_index)) == NULL)
|
|
|
|
|
return;
|
|
|
|
|
CRYPTO_r_lock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
mx = sk_CRYPTO_EX_DATA_FUNCS_num(item->meth);
|
|
|
|
|
if(mx > 0)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
2001-09-03 04:41:34 +08:00
|
|
|
storage = OPENSSL_malloc(mx * sizeof(CRYPTO_EX_DATA_FUNCS*));
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
if(!storage)
|
|
|
|
|
goto skip;
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
storage[i] = sk_CRYPTO_EX_DATA_FUNCS_value(item->meth,i);
|
|
|
|
|
}
|
|
|
|
|
skip:
|
|
|
|
|
CRYPTO_r_unlock(CRYPTO_LOCK_EX_DATA);
|
2001-09-03 04:41:34 +08:00
|
|
|
if((mx > 0) && !storage)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_INT_FREE_EX_DATA,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2001-09-03 04:41:34 +08:00
|
|
|
for(i = 0; i < mx; i++)
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
{
|
|
|
|
|
if(storage[i] && storage[i]->free_func)
|
|
|
|
|
{
|
|
|
|
|
ptr = CRYPTO_get_ex_data(ad,i);
|
|
|
|
|
storage[i]->free_func(obj,ptr,ad,i,
|
|
|
|
|
storage[i]->argl,storage[i]->argp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if(storage)
|
|
|
|
|
OPENSSL_free(storage);
|
|
|
|
|
if(ad->sk)
|
|
|
|
|
{
|
2008-06-04 19:01:43 +08:00
|
|
|
sk_void_free(ad->sk);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
ad->sk=NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/********************************************************************/
|
|
|
|
|
/* API functions that defer all "state" operations to the "ex_data"
|
|
|
|
|
* implementation we have set. */
|
|
|
|
|
|
|
|
|
|
/* Obtain an index for a new class (not the same as getting a new index within
|
|
|
|
|
* an existing class - this is actually getting a new *class*) */
|
|
|
|
|
int CRYPTO_ex_data_new_class(void)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
|
|
|
|
return EX_IMPL(new_class)();
|
1998-12-21 18:56:39 +08:00
|
|
|
}
|
|
|
|
|
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
/* Release all "ex_data" state to prevent memory leaks. This can't be made
|
|
|
|
|
* thread-safe without overhauling a lot of stuff, and shouldn't really be
|
|
|
|
|
* called under potential race-conditions anyway (it's for program shutdown
|
|
|
|
|
* after all). */
|
|
|
|
|
void CRYPTO_cleanup_all_ex_data(void)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
2001-09-03 04:05:27 +08:00
|
|
|
EX_IMPL(cleanup)();
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Inside an existing class, get/register a new index. */
|
|
|
|
|
int CRYPTO_get_ex_new_index(int class_index, long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
|
|
|
|
|
CRYPTO_EX_free *free_func)
|
|
|
|
|
{
|
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
|
|
IMPL_CHECK
|
|
|
|
|
ret = EX_IMPL(get_new_index)(class_index,
|
|
|
|
|
argl, argp, new_func, dup_func, free_func);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Initialise a new CRYPTO_EX_DATA for use in a particular class - including
|
|
|
|
|
* calling new() callbacks for each index in the class used by this variable */
|
|
|
|
|
int CRYPTO_new_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
|
|
|
|
return EX_IMPL(new_ex_data)(class_index, obj, ad);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Duplicate a CRYPTO_EX_DATA variable - including calling dup() callbacks for
|
|
|
|
|
* each index in the class used by this variable */
|
|
|
|
|
int CRYPTO_dup_ex_data(int class_index, CRYPTO_EX_DATA *to,
|
|
|
|
|
CRYPTO_EX_DATA *from)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
|
|
|
|
return EX_IMPL(dup_ex_data)(class_index, to, from);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Cleanup a CRYPTO_EX_DATA variable - including calling free() callbacks for
|
|
|
|
|
* each index in the class used by this variable */
|
|
|
|
|
void CRYPTO_free_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad)
|
|
|
|
|
{
|
|
|
|
|
IMPL_CHECK
|
2001-09-03 04:05:27 +08:00
|
|
|
EX_IMPL(free_ex_data)(class_index, obj, ad);
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For a given CRYPTO_EX_DATA variable, set the value corresponding to a
|
|
|
|
|
* particular index in the class used by this variable */
|
2000-01-24 07:41:49 +08:00
|
|
|
int CRYPTO_set_ex_data(CRYPTO_EX_DATA *ad, int idx, void *val)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (ad->sk == NULL)
|
|
|
|
|
{
|
2008-06-04 19:01:43 +08:00
|
|
|
if ((ad->sk=sk_void_new_null()) == NULL)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_CRYPTO_SET_EX_DATA,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return(0);
|
|
|
|
|
}
|
|
|
|
|
}
|
2008-06-04 19:01:43 +08:00
|
|
|
i=sk_void_num(ad->sk);
|
1998-12-21 18:56:39 +08:00
|
|
|
|
|
|
|
|
while (i <= idx)
|
|
|
|
|
{
|
2008-06-04 19:01:43 +08:00
|
|
|
if (!sk_void_push(ad->sk,NULL))
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
|
|
|
|
CRYPTOerr(CRYPTO_F_CRYPTO_SET_EX_DATA,ERR_R_MALLOC_FAILURE);
|
|
|
|
|
return(0);
|
|
|
|
|
}
|
|
|
|
|
i++;
|
|
|
|
|
}
|
2008-06-04 19:01:43 +08:00
|
|
|
sk_void_set(ad->sk,idx,val);
|
1998-12-21 18:56:39 +08:00
|
|
|
return(1);
|
|
|
|
|
}
|
|
|
|
|
|
First step in fixing "ex_data" support. Warning: big commit log ...
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
2001-09-02 03:56:46 +08:00
|
|
|
/* For a given CRYPTO_EX_DATA_ variable, get the value corresponding to a
|
|
|
|
|
* particular index in the class used by this variable */
|
2000-11-07 07:24:59 +08:00
|
|
|
void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad, int idx)
|
1998-12-21 18:56:39 +08:00
|
|
|
{
|
|
|
|
|
if (ad->sk == NULL)
|
|
|
|
|
return(0);
|
2008-06-04 19:01:43 +08:00
|
|
|
else if (idx >= sk_void_num(ad->sk))
|
1998-12-21 18:56:39 +08:00
|
|
|
return(0);
|
|
|
|
|
else
|
2008-06-04 19:01:43 +08:00
|
|
|
return(sk_void_value(ad->sk,idx));
|
1998-12-21 18:56:39 +08:00
|
|
|
}
|
|
|
|
|
|
2000-01-24 07:41:49 +08:00
|
|
|
IMPLEMENT_STACK_OF(CRYPTO_EX_DATA_FUNCS)
|
