diff options
author | Geoff Thorpe <geoff@openssl.org> | 2001-09-01 19:56:46 +0000 |
---|---|---|
committer | Geoff Thorpe <geoff@openssl.org> | 2001-09-01 19:56:46 +0000 |
commit | 3a0799977bcb154d044828e96a25a01eb478de51 (patch) | |
tree | 6a00e8b5835136f647668ee3abf99b94dff1c711 /crypto/crypto.h | |
parent | e19ea55783bc3e1af5bc6a51775ed41b638aab10 (diff) |
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.
Diffstat (limited to 'crypto/crypto.h')
-rw-r--r-- | crypto/crypto.h | 49 |
1 files changed, 41 insertions, 8 deletions
diff --git a/crypto/crypto.h b/crypto/crypto.h index 53b85238c0..b708a07dd4 100644 --- a/crypto/crypto.h +++ b/crypto/crypto.h @@ -126,7 +126,8 @@ extern "C" { #define CRYPTO_LOCK_DYNLOCK 28 #define CRYPTO_LOCK_ENGINE 29 #define CRYPTO_LOCK_UI 30 -#define CRYPTO_NUM_LOCKS 31 +#define CRYPTO_LOCK_EX_DATA 31 +#define CRYPTO_NUM_LOCKS 32 #define CRYPTO_LOCK 1 #define CRYPTO_UNLOCK 2 @@ -227,6 +228,16 @@ DECLARE_STACK_OF(CRYPTO_EX_DATA_FUNCS) #define CRYPTO_EX_INDEX_SSL_SESSION 3 #define CRYPTO_EX_INDEX_X509_STORE 4 #define CRYPTO_EX_INDEX_X509_STORE_CTX 5 +#define CRYPTO_EX_INDEX_RSA 6 +#define CRYPTO_EX_INDEX_DSA 7 +#define CRYPTO_EX_INDEX_DH 8 +#define CRYPTO_EX_INDEX_ENGINE 9 +#define CRYPTO_EX_INDEX_X509 10 +#define CRYPTO_EX_INDEX_UI 11 + +/* Dynamically assigned indexes start from this value (don't use directly, use + * via CRYPTO_ex_data_new_class). */ +#define CRYPTO_EX_INDEX_USER 100 /* This is the default callbacks, but we can have others as well: @@ -283,14 +294,31 @@ unsigned long SSLeay(void); int OPENSSL_issetugid(void); -int CRYPTO_get_ex_new_index(int idx, STACK_OF(CRYPTO_EX_DATA_FUNCS) **skp, long argl, void *argp, - CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func, CRYPTO_EX_free *free_func); +/* An opaque type representing an implementation of "ex_data" support */ +typedef struct st_CRYPTO_EX_DATA_IMPL CRYPTO_EX_DATA_IMPL; +/* Return an opaque pointer to the current "ex_data" implementation */ +const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void); +/* Sets the "ex_data" implementation to be used (if it's not too late) */ +int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i); +/* Get a new "ex_data" class, and return the corresponding "class_index" */ +int CRYPTO_ex_data_new_class(void); +/* Within a given 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); +/* Initialise/duplicate/free CRYPTO_EX_DATA variables corresponding to a given + * class (invokes whatever per-class callbacks are applicable) */ +int CRYPTO_new_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad); +int CRYPTO_dup_ex_data(int class_index, CRYPTO_EX_DATA *to, + CRYPTO_EX_DATA *from); +void CRYPTO_free_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad); +/* Get/set data in a CRYPTO_EX_DATA variable corresponding to a particular index + * (relative to the class type involved) */ int CRYPTO_set_ex_data(CRYPTO_EX_DATA *ad, int idx, void *val); void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad,int idx); -int CRYPTO_dup_ex_data(STACK_OF(CRYPTO_EX_DATA_FUNCS) *meth, CRYPTO_EX_DATA *to, - CRYPTO_EX_DATA *from); -void CRYPTO_free_ex_data(STACK_OF(CRYPTO_EX_DATA_FUNCS) *meth, void *obj, CRYPTO_EX_DATA *ad); -void CRYPTO_new_ex_data(STACK_OF(CRYPTO_EX_DATA_FUNCS) *meth, void *obj, CRYPTO_EX_DATA *ad); +/* This function cleans up all "ex_data" state. It mustn't be called under + * potential race-conditions. */ +void CRYPTO_cleanup_all_ex_data(void); int CRYPTO_get_new_lockid(char *name); @@ -398,6 +426,7 @@ void ERR_load_CRYPTO_strings(void); /* The following lines are auto generated by the script mkerr.pl. Any changes * made after this point may be overwritten when the script is next run. */ +void ERR_load_CRYPTO_strings(void); /* Error codes for the CRYPTO functions. */ @@ -406,6 +435,11 @@ void ERR_load_CRYPTO_strings(void); #define CRYPTO_F_CRYPTO_GET_NEW_DYNLOCKID 103 #define CRYPTO_F_CRYPTO_GET_NEW_LOCKID 101 #define CRYPTO_F_CRYPTO_SET_EX_DATA 102 +#define CRYPTO_F_DEF_ADD_INDEX 104 +#define CRYPTO_F_DEF_GET_CLASS 105 +#define CRYPTO_F_INT_DUP_EX_DATA 106 +#define CRYPTO_F_INT_FREE_EX_DATA 107 +#define CRYPTO_F_INT_NEW_EX_DATA 108 /* Reason codes. */ #define CRYPTO_R_NO_DYNLOCK_CREATE_CALLBACK 100 @@ -414,4 +448,3 @@ void ERR_load_CRYPTO_strings(void); } #endif #endif - |