A local copy of OpenSSL from GitHub
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

374 lines
10 KiB

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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
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.
21 years ago
  1. /*
  2. * Copyright 1995-2016 The OpenSSL Project Authors. All Rights Reserved.
  3. *
  4. * Licensed under the OpenSSL license (the "License"). You may not use
  5. * this file except in compliance with the License. You can obtain a copy
  6. * in the file LICENSE in the source distribution or at
  7. * https://www.openssl.org/source/license.html
  8. */
  9. #include "internal/cryptlib_int.h"
  10. #include <openssl/lhash.h>
  11. /*
  12. * Each structure type (sometimes called a class), that supports
  13. * exdata has a stack of callbacks for each instance.
  14. */
  15. struct ex_callback_st {
  16. long argl; /* Arbitrary long */
  17. void *argp; /* Arbitrary void * */
  18. CRYPTO_EX_new *new_func;
  19. CRYPTO_EX_free *free_func;
  20. CRYPTO_EX_dup *dup_func;
  21. };
  22. /*
  23. * The state for each class. This could just be a typedef, but
  24. * a structure allows future changes.
  25. */
  26. typedef struct ex_callbacks_st {
  27. STACK_OF(EX_CALLBACK) *meth;
  28. } EX_CALLBACKS;
  29. static EX_CALLBACKS ex_data[CRYPTO_EX_INDEX__COUNT];
  30. static CRYPTO_RWLOCK *ex_data_lock = NULL;
  31. static CRYPTO_ONCE ex_data_init = CRYPTO_ONCE_STATIC_INIT;
  32. static void do_ex_data_init(void)
  33. {
  34. ex_data_lock = CRYPTO_THREAD_lock_new();
  35. }
  36. /*
  37. * Return the EX_CALLBACKS from the |ex_data| array that corresponds to
  38. * a given class. On success, *holds the lock.*
  39. */
  40. static EX_CALLBACKS *get_and_lock(int class_index)
  41. {
  42. EX_CALLBACKS *ip;
  43. if (class_index < 0 || class_index >= CRYPTO_EX_INDEX__COUNT) {
  44. CRYPTOerr(CRYPTO_F_GET_AND_LOCK, ERR_R_PASSED_INVALID_ARGUMENT);
  45. return NULL;
  46. }
  47. CRYPTO_THREAD_run_once(&ex_data_init, do_ex_data_init);
  48. if (ex_data_lock == NULL) {
  49. /*
  50. * This can happen in normal operation when using CRYPTO_mem_leaks().
  51. * The CRYPTO_mem_leaks() function calls OPENSSL_cleanup() which cleans
  52. * up the locks. Subsequently the BIO that CRYPTO_mem_leaks() uses gets
  53. * freed, which also attempts to free the ex_data. However
  54. * CRYPTO_mem_leaks() ensures that the ex_data is freed early (i.e.
  55. * before OPENSSL_cleanup() is called), so if we get here we can safely
  56. * ignore this operation. We just treat it as an error.
  57. */
  58. return NULL;
  59. }
  60. ip = &ex_data[class_index];
  61. CRYPTO_THREAD_write_lock(ex_data_lock);
  62. return ip;
  63. }
  64. static void cleanup_cb(EX_CALLBACK *funcs)
  65. {
  66. OPENSSL_free(funcs);
  67. }
  68. /*
  69. * Release all "ex_data" state to prevent memory leaks. This can't be made
  70. * thread-safe without overhauling a lot of stuff, and shouldn't really be
  71. * called under potential race-conditions anyway (it's for program shutdown
  72. * after all).
  73. */
  74. void crypto_cleanup_all_ex_data_int(void)
  75. {
  76. int i;
  77. for (i = 0; i < CRYPTO_EX_INDEX__COUNT; ++i) {
  78. EX_CALLBACKS *ip = &ex_data[i];
  79. sk_EX_CALLBACK_pop_free(ip->meth, cleanup_cb);
  80. ip->meth = NULL;
  81. }
  82. CRYPTO_THREAD_lock_free(ex_data_lock);
  83. ex_data_lock = NULL;
  84. }
  85. /*
  86. * Unregister a new index by replacing the callbacks with no-ops.
  87. * Any in-use instances are leaked.
  88. */
  89. static void dummy_new(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx,
  90. long argl, void *argp)
  91. {
  92. }
  93. static void dummy_free(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx,
  94. long argl, void *argp)
  95. {
  96. }
  97. static int dummy_dup(CRYPTO_EX_DATA *to, CRYPTO_EX_DATA *from,
  98. void *from_d, int idx,
  99. long argl, void *argp)
  100. {
  101. return 0;
  102. }
  103. int CRYPTO_free_ex_index(int class_index, int idx)
  104. {
  105. EX_CALLBACKS *ip = get_and_lock(class_index);
  106. EX_CALLBACK *a;
  107. int toret = 0;
  108. if (ip == NULL)
  109. return 0;
  110. if (idx < 0 || idx >= sk_EX_CALLBACK_num(ip->meth))
  111. goto err;
  112. a = sk_EX_CALLBACK_value(ip->meth, idx);
  113. if (a == NULL)
  114. goto err;
  115. a->new_func = dummy_new;
  116. a->dup_func = dummy_dup;
  117. a->free_func = dummy_free;
  118. toret = 1;
  119. err:
  120. CRYPTO_THREAD_unlock(ex_data_lock);
  121. return toret;
  122. }
  123. /*
  124. * Register a new index.
  125. */
  126. int CRYPTO_get_ex_new_index(int class_index, long argl, void *argp,
  127. CRYPTO_EX_new *new_func, CRYPTO_EX_dup *dup_func,
  128. CRYPTO_EX_free *free_func)
  129. {
  130. int toret = -1;
  131. EX_CALLBACK *a;
  132. EX_CALLBACKS *ip = get_and_lock(class_index);
  133. if (ip == NULL)
  134. return -1;
  135. if (ip->meth == NULL) {
  136. ip->meth = sk_EX_CALLBACK_new_null();
  137. /* We push an initial value on the stack because the SSL
  138. * "app_data" routines use ex_data index zero. See RT 3710. */
  139. if (ip->meth == NULL
  140. || !sk_EX_CALLBACK_push(ip->meth, NULL)) {
  141. CRYPTOerr(CRYPTO_F_CRYPTO_GET_EX_NEW_INDEX, ERR_R_MALLOC_FAILURE);
  142. goto err;
  143. }
  144. }
  145. a = (EX_CALLBACK *)OPENSSL_malloc(sizeof(*a));
  146. if (a == NULL) {
  147. CRYPTOerr(CRYPTO_F_CRYPTO_GET_EX_NEW_INDEX, ERR_R_MALLOC_FAILURE);
  148. goto err;
  149. }
  150. a->argl = argl;
  151. a->argp = argp;
  152. a->new_func = new_func;
  153. a->dup_func = dup_func;
  154. a->free_func = free_func;
  155. if (!sk_EX_CALLBACK_push(ip->meth, NULL)) {
  156. CRYPTOerr(CRYPTO_F_CRYPTO_GET_EX_NEW_INDEX, ERR_R_MALLOC_FAILURE);
  157. OPENSSL_free(a);
  158. goto err;
  159. }
  160. toret = sk_EX_CALLBACK_num(ip->meth) - 1;
  161. (void)sk_EX_CALLBACK_set(ip->meth, toret, a);
  162. err:
  163. CRYPTO_THREAD_unlock(ex_data_lock);
  164. return toret;
  165. }
  166. /*
  167. * Initialise a new CRYPTO_EX_DATA for use in a particular class - including
  168. * calling new() callbacks for each index in the class used by this variable
  169. * Thread-safe by copying a class's array of "EX_CALLBACK" entries
  170. * in the lock, then using them outside the lock. Note this only applies
  171. * to the global "ex_data" state (ie. class definitions), not 'ad' itself.
  172. */
  173. int CRYPTO_new_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad)
  174. {
  175. int mx, i;
  176. void *ptr;
  177. EX_CALLBACK **storage = NULL;
  178. EX_CALLBACK *stack[10];
  179. EX_CALLBACKS *ip = get_and_lock(class_index);
  180. if (ip == NULL)
  181. return 0;
  182. ad->sk = NULL;
  183. mx = sk_EX_CALLBACK_num(ip->meth);
  184. if (mx > 0) {
  185. if (mx < (int)OSSL_NELEM(stack))
  186. storage = stack;
  187. else
  188. storage = OPENSSL_malloc(sizeof(*storage) * mx);
  189. if (storage != NULL)
  190. for (i = 0; i < mx; i++)
  191. storage[i] = sk_EX_CALLBACK_value(ip->meth, i);
  192. }
  193. CRYPTO_THREAD_unlock(ex_data_lock);
  194. if (mx > 0 && storage == NULL) {
  195. CRYPTOerr(CRYPTO_F_CRYPTO_NEW_EX_DATA, ERR_R_MALLOC_FAILURE);
  196. return 0;
  197. }
  198. for (i = 0; i < mx; i++) {
  199. if (storage[i] && storage[i]->new_func) {
  200. ptr = CRYPTO_get_ex_data(ad, i);
  201. storage[i]->new_func(obj, ptr, ad, i,
  202. storage[i]->argl, storage[i]->argp);
  203. }
  204. }
  205. if (storage != stack)
  206. OPENSSL_free(storage);
  207. return 1;
  208. }
  209. /*
  210. * Duplicate a CRYPTO_EX_DATA variable - including calling dup() callbacks
  211. * for each index in the class used by this variable
  212. */
  213. int CRYPTO_dup_ex_data(int class_index, CRYPTO_EX_DATA *to,
  214. CRYPTO_EX_DATA *from)
  215. {
  216. int mx, j, i;
  217. char *ptr;
  218. EX_CALLBACK *stack[10];
  219. EX_CALLBACK **storage = NULL;
  220. EX_CALLBACKS *ip;
  221. if (from->sk == NULL)
  222. /* Nothing to copy over */
  223. return 1;
  224. if ((ip = get_and_lock(class_index)) == NULL)
  225. return 0;
  226. mx = sk_EX_CALLBACK_num(ip->meth);
  227. j = sk_void_num(from->sk);
  228. if (j < mx)
  229. mx = j;
  230. if (mx > 0) {
  231. if (mx < (int)OSSL_NELEM(stack))
  232. storage = stack;
  233. else
  234. storage = OPENSSL_malloc(sizeof(*storage) * mx);
  235. if (storage != NULL)
  236. for (i = 0; i < mx; i++)
  237. storage[i] = sk_EX_CALLBACK_value(ip->meth, i);
  238. }
  239. CRYPTO_THREAD_unlock(ex_data_lock);
  240. if (mx > 0 && storage == NULL) {
  241. CRYPTOerr(CRYPTO_F_CRYPTO_DUP_EX_DATA, ERR_R_MALLOC_FAILURE);
  242. return 0;
  243. }
  244. for (i = 0; i < mx; i++) {
  245. ptr = CRYPTO_get_ex_data(from, i);
  246. if (storage[i] && storage[i]->dup_func)
  247. storage[i]->dup_func(to, from, &ptr, i,
  248. storage[i]->argl, storage[i]->argp);
  249. CRYPTO_set_ex_data(to, i, ptr);
  250. }
  251. if (storage != stack)
  252. OPENSSL_free(storage);
  253. return 1;
  254. }
  255. /*
  256. * Cleanup a CRYPTO_EX_DATA variable - including calling free() callbacks for
  257. * each index in the class used by this variable
  258. */
  259. void CRYPTO_free_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad)
  260. {
  261. int mx, i;
  262. EX_CALLBACKS *ip;
  263. void *ptr;
  264. EX_CALLBACK *stack[10];
  265. EX_CALLBACK **storage = NULL;
  266. if ((ip = get_and_lock(class_index)) == NULL)
  267. return;
  268. mx = sk_EX_CALLBACK_num(ip->meth);
  269. if (mx > 0) {
  270. if (mx < (int)OSSL_NELEM(stack))
  271. storage = stack;
  272. else
  273. storage = OPENSSL_malloc(sizeof(*storage) * mx);
  274. if (storage != NULL)
  275. for (i = 0; i < mx; i++)
  276. storage[i] = sk_EX_CALLBACK_value(ip->meth, i);
  277. }
  278. CRYPTO_THREAD_unlock(ex_data_lock);
  279. if (mx > 0 && storage == NULL) {
  280. CRYPTOerr(CRYPTO_F_CRYPTO_FREE_EX_DATA, ERR_R_MALLOC_FAILURE);
  281. return;
  282. }
  283. for (i = 0; i < mx; i++) {
  284. if (storage[i] && storage[i]->free_func) {
  285. ptr = CRYPTO_get_ex_data(ad, i);
  286. storage[i]->free_func(obj, ptr, ad, i,
  287. storage[i]->argl, storage[i]->argp);
  288. }
  289. }
  290. if (storage != stack)
  291. OPENSSL_free(storage);
  292. sk_void_free(ad->sk);
  293. ad->sk = NULL;
  294. }
  295. /*
  296. * For a given CRYPTO_EX_DATA variable, set the value corresponding to a
  297. * particular index in the class used by this variable
  298. */
  299. int CRYPTO_set_ex_data(CRYPTO_EX_DATA *ad, int idx, void *val)
  300. {
  301. int i;
  302. if (ad->sk == NULL) {
  303. if ((ad->sk = sk_void_new_null()) == NULL) {
  304. CRYPTOerr(CRYPTO_F_CRYPTO_SET_EX_DATA, ERR_R_MALLOC_FAILURE);
  305. return 0;
  306. }
  307. }
  308. for (i = sk_void_num(ad->sk); i <= idx; ++i) {
  309. if (!sk_void_push(ad->sk, NULL)) {
  310. CRYPTOerr(CRYPTO_F_CRYPTO_SET_EX_DATA, ERR_R_MALLOC_FAILURE);
  311. return 0;
  312. }
  313. }
  314. sk_void_set(ad->sk, idx, val);
  315. return 1;
  316. }
  317. /*
  318. * For a given CRYPTO_EX_DATA_ variable, get the value corresponding to a
  319. * particular index in the class used by this variable
  320. */
  321. void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad, int idx)
  322. {
  323. if (ad->sk == NULL || idx >= sk_void_num(ad->sk))
  324. return NULL;
  325. return sk_void_value(ad->sk, idx);
  326. }