2016-05-17 19:38:09 +00:00
|
|
|
/*
|
2023-09-07 08:59:15 +00:00
|
|
|
* Copyright 1995-2023 The OpenSSL Project Authors. All Rights Reserved.
|
2001-09-04 11:02:23 +00:00
|
|
|
*
|
2018-12-06 13:03:01 +00:00
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
2016-05-17 19:38:09 +00:00
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
|
* https://www.openssl.org/source/license.html
|
2001-09-04 11:02:23 +00:00
|
|
|
*/
|
1998-12-21 10:56:39 +00:00
|
|
|
|
2021-04-26 10:35:17 +00:00
|
|
|
#include <stdlib.h>
|
2019-09-27 22:45:33 +00:00
|
|
|
#include "crypto/cryptlib.h"
|
2016-07-19 17:42:11 +00:00
|
|
|
#include "internal/thread_once.h"
|
1998-12-21 10:56:39 +00:00
|
|
|
|
2021-02-24 08:07:52 +00:00
|
|
|
int ossl_do_ex_data_init(OSSL_LIB_CTX *ctx)
|
2016-03-05 21:54:02 +00:00
|
|
|
{
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ctx);
|
2019-05-01 10:02:43 +00:00
|
|
|
|
|
|
|
|
if (global == NULL)
|
2018-04-20 13:45:06 +00:00
|
|
|
return 0;
|
2019-05-01 10:02:43 +00:00
|
|
|
|
|
|
|
|
global->ex_data_lock = CRYPTO_THREAD_lock_new();
|
|
|
|
|
return global->ex_data_lock != NULL;
|
2016-03-11 21:53:18 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-22 03:40:55 +00:00
|
|
|
/*
|
2015-07-21 14:06:03 +00:00
|
|
|
* Return the EX_CALLBACKS from the |ex_data| array that corresponds to
|
2015-04-24 20:33:34 +00:00
|
|
|
* a given class. On success, *holds the lock.*
|
2020-02-23 09:01:45 +00:00
|
|
|
* The |global| parameter is assumed to be non null (checked by the caller).
|
2023-05-11 10:25:07 +00:00
|
|
|
* If |read| is 1 then a read lock is obtained. Otherwise it is a write lock.
|
2015-01-22 03:40:55 +00:00
|
|
|
*/
|
2023-05-11 10:25:07 +00:00
|
|
|
static EX_CALLBACKS *get_and_lock(OSSL_EX_DATA_GLOBAL *global, int class_index,
|
|
|
|
|
int read)
|
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-01 19:56:46 +00:00
|
|
|
{
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACKS *ip;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
|
|
|
|
if (class_index < 0 || class_index >= CRYPTO_EX_INDEX__COUNT) {
|
2020-11-04 11:23:19 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_PASSED_INVALID_ARGUMENT);
|
2015-04-24 20:33:34 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-23 09:01:45 +00:00
|
|
|
if (global->ex_data_lock == NULL) {
|
2016-04-14 20:28:54 +00:00
|
|
|
/*
|
2019-12-04 18:15:08 +00:00
|
|
|
* If we get here, someone (who?) cleaned up the lock, so just
|
|
|
|
|
* treat it as an error.
|
2016-04-14 20:28:54 +00:00
|
|
|
*/
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
if (read) {
|
|
|
|
|
if (!CRYPTO_THREAD_read_lock(global->ex_data_lock))
|
|
|
|
|
return NULL;
|
|
|
|
|
} else {
|
|
|
|
|
if (!CRYPTO_THREAD_write_lock(global->ex_data_lock))
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-12 10:07:39 +00:00
|
|
|
ip = &global->ex_data[class_index];
|
2015-04-24 20:33:34 +00:00
|
|
|
return ip;
|
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-01 19:56:46 +00:00
|
|
|
}
|
2015-01-22 03:40:55 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
static void cleanup_cb(EX_CALLBACK *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-01 19:56:46 +00:00
|
|
|
{
|
2001-09-02 20:41:34 +00: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-01 19:56:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2015-04-24 20:33:34 +00: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).
|
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-01 19:56:46 +00:00
|
|
|
*/
|
2021-02-24 08:07:52 +00:00
|
|
|
void ossl_crypto_cleanup_all_ex_data_int(OSSL_LIB_CTX *ctx)
|
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-01 19:56:46 +00:00
|
|
|
{
|
2015-04-24 20:33:34 +00:00
|
|
|
int i;
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ctx);
|
2019-05-01 10:02:43 +00:00
|
|
|
|
|
|
|
|
if (global == NULL)
|
|
|
|
|
return;
|
2015-01-22 03:40:55 +00:00
|
|
|
|
2015-04-24 20:33:34 +00:00
|
|
|
for (i = 0; i < CRYPTO_EX_INDEX__COUNT; ++i) {
|
2019-05-01 10:02:43 +00:00
|
|
|
EX_CALLBACKS *ip = &global->ex_data[i];
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
sk_EX_CALLBACK_pop_free(ip->meth, cleanup_cb);
|
2015-04-24 20:33:34 +00:00
|
|
|
ip->meth = 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-01 19:56:46 +00:00
|
|
|
}
|
2016-04-14 20:28:54 +00:00
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_lock_free(global->ex_data_lock);
|
|
|
|
|
global->ex_data_lock = 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-01 19:56:46 +00:00
|
|
|
}
|
2015-01-22 03:40:55 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Unregister a new index by replacing the callbacks with no-ops.
|
|
|
|
|
* Any in-use instances are leaked.
|
|
|
|
|
*/
|
|
|
|
|
static void dummy_new(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx,
|
|
|
|
|
long argl, void *argp)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void dummy_free(void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx,
|
|
|
|
|
long argl, void *argp)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-31 10:04:48 +00:00
|
|
|
static int dummy_dup(CRYPTO_EX_DATA *to, const CRYPTO_EX_DATA *from,
|
2017-03-20 16:29:28 +00:00
|
|
|
void **from_d, int idx,
|
2015-07-21 14:06:03 +00:00
|
|
|
long argl, void *argp)
|
|
|
|
|
{
|
2017-03-19 15:14:33 +00:00
|
|
|
return 1;
|
2015-07-21 14:06:03 +00:00
|
|
|
}
|
|
|
|
|
|
2021-02-24 08:07:52 +00:00
|
|
|
int ossl_crypto_free_ex_index_ex(OSSL_LIB_CTX *ctx, int class_index, int idx)
|
2015-07-21 14:06:03 +00:00
|
|
|
{
|
2019-11-22 09:44:02 +00:00
|
|
|
EX_CALLBACKS *ip;
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACK *a;
|
|
|
|
|
int toret = 0;
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ctx);
|
2019-05-01 10:02:43 +00:00
|
|
|
|
|
|
|
|
if (global == NULL)
|
2019-05-07 00:57:34 +00:00
|
|
|
return 0;
|
2015-07-21 14:06:03 +00:00
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 0);
|
2015-07-21 14:06:03 +00:00
|
|
|
if (ip == NULL)
|
|
|
|
|
return 0;
|
2020-02-23 09:01:45 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
if (idx < 0 || idx >= sk_EX_CALLBACK_num(ip->meth))
|
|
|
|
|
goto err;
|
|
|
|
|
a = sk_EX_CALLBACK_value(ip->meth, idx);
|
|
|
|
|
if (a == NULL)
|
|
|
|
|
goto err;
|
|
|
|
|
a->new_func = dummy_new;
|
|
|
|
|
a->dup_func = dummy_dup;
|
|
|
|
|
a->free_func = dummy_free;
|
|
|
|
|
toret = 1;
|
|
|
|
|
err:
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
2015-07-21 14:06:03 +00:00
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
int CRYPTO_free_ex_index(int class_index, int idx)
|
|
|
|
|
{
|
2021-02-24 08:07:52 +00:00
|
|
|
return ossl_crypto_free_ex_index_ex(NULL, class_index, idx);
|
2019-05-01 10:02:43 +00: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-01 19:56:46 +00:00
|
|
|
/*
|
2015-07-21 14:06:03 +00:00
|
|
|
* Register a new 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-01 19:56:46 +00:00
|
|
|
*/
|
2021-02-24 08:07:52 +00:00
|
|
|
int ossl_crypto_get_ex_new_index_ex(OSSL_LIB_CTX *ctx, int class_index,
|
|
|
|
|
long argl, void *argp,
|
|
|
|
|
CRYPTO_EX_new *new_func,
|
|
|
|
|
CRYPTO_EX_dup *dup_func,
|
2021-04-26 10:35:17 +00:00
|
|
|
CRYPTO_EX_free *free_func,
|
|
|
|
|
int priority)
|
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-01 19:56:46 +00:00
|
|
|
{
|
|
|
|
|
int toret = -1;
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACK *a;
|
2019-05-01 10:02:43 +00:00
|
|
|
EX_CALLBACKS *ip;
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ctx);
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
if (global == NULL)
|
2019-05-07 01:07:41 +00:00
|
|
|
return -1;
|
2019-05-01 10:02:43 +00:00
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 0);
|
2015-07-21 14:06:03 +00:00
|
|
|
if (ip == 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-01 19:56:46 +00:00
|
|
|
return -1;
|
2016-03-12 19:46:13 +00:00
|
|
|
|
|
|
|
|
if (ip->meth == NULL) {
|
|
|
|
|
ip->meth = sk_EX_CALLBACK_new_null();
|
|
|
|
|
/* We push an initial value on the stack because the SSL
|
|
|
|
|
* "app_data" routines use ex_data index zero. See RT 3710. */
|
|
|
|
|
if (ip->meth == NULL
|
|
|
|
|
|| !sk_EX_CALLBACK_push(ip->meth, NULL)) {
|
2023-09-19 18:15:18 +00:00
|
|
|
sk_EX_CALLBACK_free(ip->meth);
|
|
|
|
|
ip->meth = NULL;
|
2022-09-29 11:57:34 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_CRYPTO_LIB);
|
2016-03-12 19:46:13 +00:00
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
a = (EX_CALLBACK *)OPENSSL_malloc(sizeof(*a));
|
2022-09-29 11:57:34 +00:00
|
|
|
if (a == NULL)
|
2015-04-24 20:33:34 +00:00
|
|
|
goto err;
|
1998-12-21 10:56:39 +00:00
|
|
|
a->argl = argl;
|
|
|
|
|
a->argp = argp;
|
|
|
|
|
a->new_func = new_func;
|
|
|
|
|
a->dup_func = dup_func;
|
|
|
|
|
a->free_func = free_func;
|
2021-04-26 10:35:17 +00:00
|
|
|
a->priority = priority;
|
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-01 19:56:46 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
if (!sk_EX_CALLBACK_push(ip->meth, NULL)) {
|
2022-09-29 11:57:34 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_CRYPTO_LIB);
|
2015-04-24 20:33:34 +00:00
|
|
|
OPENSSL_free(a);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
2015-07-21 14:06:03 +00:00
|
|
|
toret = sk_EX_CALLBACK_num(ip->meth) - 1;
|
|
|
|
|
(void)sk_EX_CALLBACK_set(ip->meth, toret, 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-01 19:56:46 +00:00
|
|
|
|
2015-04-24 20:33:34 +00:00
|
|
|
err:
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
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-01 19:56:46 +00:00
|
|
|
return toret;
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
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)
|
|
|
|
|
{
|
2021-02-24 08:07:52 +00:00
|
|
|
return ossl_crypto_get_ex_new_index_ex(NULL, class_index, argl, argp,
|
2021-04-26 10:35:17 +00:00
|
|
|
new_func, dup_func, free_func, 0);
|
2019-05-01 10:02:43 +00: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-01 19:56:46 +00:00
|
|
|
/*
|
2015-04-24 20:33:34 +00:00
|
|
|
* 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
|
2015-07-21 14:06:03 +00:00
|
|
|
* Thread-safe by copying a class's array of "EX_CALLBACK" entries
|
2015-04-24 20:33:34 +00:00
|
|
|
* in the lock, then using them outside the lock. Note this only applies
|
|
|
|
|
* to the global "ex_data" state (ie. class definitions), not 'ad' itself.
|
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-01 19:56:46 +00:00
|
|
|
*/
|
2021-02-24 08:07:52 +00:00
|
|
|
int ossl_crypto_new_ex_data_ex(OSSL_LIB_CTX *ctx, int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *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-01 19:56:46 +00:00
|
|
|
{
|
2001-09-02 20:41:34 +00: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-01 19:56:46 +00:00
|
|
|
void *ptr;
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACK **storage = NULL;
|
|
|
|
|
EX_CALLBACK *stack[10];
|
2019-05-01 10:02:43 +00:00
|
|
|
EX_CALLBACKS *ip;
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ctx);
|
2019-05-01 10:02:43 +00:00
|
|
|
|
|
|
|
|
if (global == NULL)
|
|
|
|
|
return 0;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 1);
|
2015-07-21 14:06:03 +00:00
|
|
|
if (ip == 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-01 19:56:46 +00:00
|
|
|
return 0;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
ad->ctx = ctx;
|
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-01 19:56:46 +00:00
|
|
|
ad->sk = NULL;
|
2015-07-21 14:06:03 +00:00
|
|
|
mx = sk_EX_CALLBACK_num(ip->meth);
|
2001-09-02 20:41:34 +00:00
|
|
|
if (mx > 0) {
|
2015-04-24 20:33:34 +00:00
|
|
|
if (mx < (int)OSSL_NELEM(stack))
|
|
|
|
|
storage = stack;
|
|
|
|
|
else
|
|
|
|
|
storage = OPENSSL_malloc(sizeof(*storage) * mx);
|
2015-10-30 11:12:26 +00:00
|
|
|
if (storage != NULL)
|
2015-04-24 20:33:34 +00:00
|
|
|
for (i = 0; i < mx; i++)
|
2015-07-21 14:06:03 +00:00
|
|
|
storage[i] = sk_EX_CALLBACK_value(ip->meth, 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-01 19:56:46 +00:00
|
|
|
}
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2022-09-29 11:57:34 +00:00
|
|
|
if (mx > 0 && storage == 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-01 19:56:46 +00:00
|
|
|
return 0;
|
2001-09-02 20:41:34 +00:00
|
|
|
for (i = 0; i < mx; i++) {
|
2019-04-06 09:16:59 +00:00
|
|
|
if (storage[i] != NULL && storage[i]->new_func != 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-01 19:56:46 +00:00
|
|
|
ptr = CRYPTO_get_ex_data(ad, i);
|
|
|
|
|
storage[i]->new_func(obj, ptr, ad, i,
|
|
|
|
|
storage[i]->argl, storage[i]->argp);
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-04-24 20:33:34 +00:00
|
|
|
if (storage != stack)
|
|
|
|
|
OPENSSL_free(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-01 19:56:46 +00:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
int CRYPTO_new_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad)
|
|
|
|
|
{
|
2021-02-24 08:07:52 +00:00
|
|
|
return ossl_crypto_new_ex_data_ex(NULL, class_index, obj, ad);
|
2019-05-01 10:02:43 +00:00
|
|
|
}
|
|
|
|
|
|
2015-04-24 20:33:34 +00:00
|
|
|
/*
|
|
|
|
|
* 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,
|
2016-07-31 10:04:48 +00:00
|
|
|
const CRYPTO_EX_DATA *from)
|
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-01 19:56:46 +00:00
|
|
|
{
|
2001-09-02 20:41:34 +00:00
|
|
|
int mx, j, i;
|
2017-03-19 15:14:33 +00:00
|
|
|
void *ptr;
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACK *stack[10];
|
|
|
|
|
EX_CALLBACK **storage = NULL;
|
|
|
|
|
EX_CALLBACKS *ip;
|
2017-03-19 15:14:33 +00:00
|
|
|
int toret = 0;
|
2020-02-23 09:01:45 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
to->ctx = from->ctx;
|
2015-04-24 20:33:34 +00:00
|
|
|
if (from->sk == NULL)
|
|
|
|
|
/* Nothing to copy over */
|
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-01 19:56:46 +00:00
|
|
|
return 1;
|
2020-02-23 09:01:45 +00:00
|
|
|
|
2020-10-15 09:55:50 +00:00
|
|
|
global = ossl_lib_ctx_get_ex_data_global(from->ctx);
|
2020-02-23 09:01:45 +00:00
|
|
|
if (global == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 1);
|
2020-02-23 09:01:45 +00:00
|
|
|
if (ip == 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-01 19:56:46 +00:00
|
|
|
return 0;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
mx = sk_EX_CALLBACK_num(ip->meth);
|
2008-06-04 11:01:43 +00:00
|
|
|
j = sk_void_num(from->sk);
|
2001-09-02 20:41:34 +00:00
|
|
|
if (j < mx)
|
|
|
|
|
mx = j;
|
|
|
|
|
if (mx > 0) {
|
2015-04-24 20:33:34 +00:00
|
|
|
if (mx < (int)OSSL_NELEM(stack))
|
|
|
|
|
storage = stack;
|
|
|
|
|
else
|
|
|
|
|
storage = OPENSSL_malloc(sizeof(*storage) * mx);
|
2015-10-30 11:12:26 +00:00
|
|
|
if (storage != NULL)
|
2015-04-24 20:33:34 +00:00
|
|
|
for (i = 0; i < mx; i++)
|
2015-07-21 14:06:03 +00:00
|
|
|
storage[i] = sk_EX_CALLBACK_value(ip->meth, 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-01 19:56:46 +00:00
|
|
|
}
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2017-03-19 15:14:33 +00:00
|
|
|
if (mx == 0)
|
|
|
|
|
return 1;
|
2022-09-29 11:57:34 +00:00
|
|
|
if (storage == 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-01 19:56:46 +00:00
|
|
|
return 0;
|
2017-04-26 18:05:49 +00:00
|
|
|
/*
|
|
|
|
|
* Make sure the ex_data stack is at least |mx| elements long to avoid
|
|
|
|
|
* issues in the for loop that follows; so go get the |mx|'th element
|
|
|
|
|
* (if it does not exist CRYPTO_get_ex_data() returns NULL), and assign
|
|
|
|
|
* to itself. This is normally a no-op; but ensures the stack is the
|
|
|
|
|
* proper size
|
|
|
|
|
*/
|
|
|
|
|
if (!CRYPTO_set_ex_data(to, mx - 1, CRYPTO_get_ex_data(to, mx - 1)))
|
2017-03-19 15:14:33 +00:00
|
|
|
goto err;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2001-09-02 20:41:34 +00: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-01 19:56:46 +00:00
|
|
|
ptr = CRYPTO_get_ex_data(from, i);
|
2019-04-06 09:16:59 +00:00
|
|
|
if (storage[i] != NULL && storage[i]->dup_func != NULL)
|
2017-03-19 15:14:33 +00:00
|
|
|
if (!storage[i]->dup_func(to, from, &ptr, i,
|
|
|
|
|
storage[i]->argl, storage[i]->argp))
|
|
|
|
|
goto 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-01 19:56:46 +00:00
|
|
|
CRYPTO_set_ex_data(to, i, ptr);
|
|
|
|
|
}
|
2017-03-19 15:14:33 +00:00
|
|
|
toret = 1;
|
|
|
|
|
err:
|
2015-04-24 20:33:34 +00:00
|
|
|
if (storage != stack)
|
|
|
|
|
OPENSSL_free(storage);
|
2017-03-19 15:14:33 +00:00
|
|
|
return toret;
|
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-01 19:56:46 +00:00
|
|
|
}
|
|
|
|
|
|
2021-04-26 10:35:17 +00:00
|
|
|
struct ex_callback_entry {
|
|
|
|
|
const EX_CALLBACK *excb;
|
|
|
|
|
int index;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int ex_callback_compare(const void *a, const void *b)
|
|
|
|
|
{
|
|
|
|
|
const struct ex_callback_entry *ap = (const struct ex_callback_entry *)a;
|
|
|
|
|
const struct ex_callback_entry *bp = (const struct ex_callback_entry *)b;
|
|
|
|
|
|
|
|
|
|
if (ap->excb == bp->excb)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (ap->excb == NULL)
|
|
|
|
|
return 1;
|
|
|
|
|
if (bp->excb == NULL)
|
|
|
|
|
return -1;
|
|
|
|
|
if (ap->excb->priority == bp->excb->priority)
|
|
|
|
|
return 0;
|
|
|
|
|
return ap->excb->priority > bp->excb->priority ? -1 : 1;
|
|
|
|
|
}
|
2015-04-24 20:33:34 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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)
|
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-01 19:56:46 +00:00
|
|
|
{
|
2001-09-02 20:41:34 +00:00
|
|
|
int mx, i;
|
2015-07-21 14:06:03 +00:00
|
|
|
EX_CALLBACKS *ip;
|
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-01 19:56:46 +00:00
|
|
|
void *ptr;
|
2021-04-26 10:35:17 +00:00
|
|
|
const EX_CALLBACK *f;
|
|
|
|
|
struct ex_callback_entry stack[10];
|
|
|
|
|
struct ex_callback_entry *storage = NULL;
|
2020-10-15 09:55:50 +00:00
|
|
|
OSSL_EX_DATA_GLOBAL *global = ossl_lib_ctx_get_ex_data_global(ad->ctx);
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2019-05-01 10:02:43 +00:00
|
|
|
if (global == NULL)
|
2017-02-01 17:29:47 +00:00
|
|
|
goto err;
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 1);
|
2020-02-23 09:01:45 +00:00
|
|
|
if (ip == NULL)
|
|
|
|
|
goto err;
|
|
|
|
|
|
2015-07-21 14:06:03 +00:00
|
|
|
mx = sk_EX_CALLBACK_num(ip->meth);
|
2001-09-02 20:41:34 +00:00
|
|
|
if (mx > 0) {
|
2015-04-24 20:33:34 +00:00
|
|
|
if (mx < (int)OSSL_NELEM(stack))
|
|
|
|
|
storage = stack;
|
|
|
|
|
else
|
|
|
|
|
storage = OPENSSL_malloc(sizeof(*storage) * mx);
|
2015-10-30 11:12:26 +00:00
|
|
|
if (storage != NULL)
|
2021-04-26 10:35:17 +00:00
|
|
|
for (i = 0; i < mx; i++) {
|
|
|
|
|
storage[i].excb = sk_EX_CALLBACK_value(ip->meth, i);
|
|
|
|
|
storage[i].index = 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-01 19:56:46 +00:00
|
|
|
}
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
2015-04-24 20:33:34 +00:00
|
|
|
|
2021-04-26 10:35:17 +00:00
|
|
|
if (storage != NULL) {
|
|
|
|
|
/* Sort according to priority. High priority first */
|
|
|
|
|
qsort(storage, mx, sizeof(*storage), ex_callback_compare);
|
|
|
|
|
for (i = 0; i < mx; i++) {
|
|
|
|
|
f = storage[i].excb;
|
|
|
|
|
|
|
|
|
|
if (f != NULL && f->free_func != NULL) {
|
|
|
|
|
ptr = CRYPTO_get_ex_data(ad, storage[i].index);
|
|
|
|
|
f->free_func(obj, ptr, ad, storage[i].index, f->argl, f->argp);
|
|
|
|
|
}
|
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-01 19:56:46 +00:00
|
|
|
}
|
|
|
|
|
}
|
2015-04-24 20:33:34 +00:00
|
|
|
|
|
|
|
|
if (storage != stack)
|
|
|
|
|
OPENSSL_free(storage);
|
2017-02-01 17:29:47 +00:00
|
|
|
err:
|
2015-05-01 18:37:16 +00:00
|
|
|
sk_void_free(ad->sk);
|
|
|
|
|
ad->sk = NULL;
|
2019-05-01 10:02:43 +00:00
|
|
|
ad->ctx = 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-01 19:56:46 +00:00
|
|
|
}
|
|
|
|
|
|
2019-02-08 15:46:28 +00:00
|
|
|
/*
|
|
|
|
|
* Allocate a given CRYPTO_EX_DATA item using the class specific allocation
|
|
|
|
|
* function
|
|
|
|
|
*/
|
|
|
|
|
int CRYPTO_alloc_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *ad,
|
|
|
|
|
int idx)
|
|
|
|
|
{
|
|
|
|
|
void *curval;
|
|
|
|
|
|
|
|
|
|
curval = CRYPTO_get_ex_data(ad, idx);
|
|
|
|
|
/* Already there, no need to allocate */
|
|
|
|
|
if (curval != NULL)
|
|
|
|
|
return 1;
|
|
|
|
|
|
2021-01-26 17:00:25 +00:00
|
|
|
return ossl_crypto_alloc_ex_data_intern(class_index, obj, ad, idx);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ossl_crypto_alloc_ex_data_intern(int class_index, void *obj,
|
|
|
|
|
CRYPTO_EX_DATA *ad, int idx)
|
|
|
|
|
{
|
|
|
|
|
EX_CALLBACK *f;
|
|
|
|
|
EX_CALLBACKS *ip;
|
|
|
|
|
OSSL_EX_DATA_GLOBAL *global;
|
|
|
|
|
|
2020-10-15 09:55:50 +00:00
|
|
|
global = ossl_lib_ctx_get_ex_data_global(ad->ctx);
|
2020-02-23 09:01:45 +00:00
|
|
|
if (global == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2023-05-11 10:25:07 +00:00
|
|
|
ip = get_and_lock(global, class_index, 1);
|
2019-04-06 09:16:59 +00:00
|
|
|
if (ip == NULL)
|
|
|
|
|
return 0;
|
2019-02-08 15:46:28 +00:00
|
|
|
f = sk_EX_CALLBACK_value(ip->meth, idx);
|
2019-05-01 10:02:43 +00:00
|
|
|
CRYPTO_THREAD_unlock(global->ex_data_lock);
|
2019-02-08 15:46:28 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This should end up calling CRYPTO_set_ex_data(), which allocates
|
|
|
|
|
* everything necessary to support placing the new data in the right spot.
|
|
|
|
|
*/
|
2019-04-06 09:16:59 +00:00
|
|
|
if (f->new_func == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-08-02 01:56:46 +00:00
|
|
|
f->new_func(obj, NULL, ad, idx, f->argl, f->argp);
|
2019-02-08 15:46:28 +00: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-01 19:56:46 +00: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-23 23:41:49 +00:00
|
|
|
int CRYPTO_set_ex_data(CRYPTO_EX_DATA *ad, int idx, void *val)
|
1998-12-21 10:56:39 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
2015-01-22 03:40:55 +00:00
|
|
|
|
1998-12-21 10:56:39 +00:00
|
|
|
if (ad->sk == NULL) {
|
2008-06-04 11:01:43 +00:00
|
|
|
if ((ad->sk = sk_void_new_null()) == NULL) {
|
2022-09-29 11:57:34 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_CRYPTO_LIB);
|
2015-04-24 20:33:34 +00:00
|
|
|
return 0;
|
2015-01-22 03:40:55 +00:00
|
|
|
}
|
1998-12-21 10:56:39 +00:00
|
|
|
}
|
2015-01-22 03:40:55 +00:00
|
|
|
|
2015-04-24 20:33:34 +00:00
|
|
|
for (i = sk_void_num(ad->sk); i <= idx; ++i) {
|
2008-06-04 11:01:43 +00:00
|
|
|
if (!sk_void_push(ad->sk, NULL)) {
|
2022-09-29 11:57:34 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_CRYPTO_LIB);
|
2015-04-24 20:33:34 +00:00
|
|
|
return 0;
|
1998-12-21 10:56:39 +00:00
|
|
|
}
|
|
|
|
|
}
|
2020-09-10 15:34:17 +00:00
|
|
|
if (sk_void_set(ad->sk, idx, val) != val) {
|
|
|
|
|
/* Probably the index is out of bounds */
|
2020-11-04 11:23:19 +00:00
|
|
|
ERR_raise(ERR_LIB_CRYPTO, ERR_R_PASSED_INVALID_ARGUMENT);
|
2020-09-10 15:34:17 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2015-04-24 20:33:34 +00:00
|
|
|
return 1;
|
1998-12-21 10:56:39 +00:00
|
|
|
}
|
2015-01-22 03:40:55 +00: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-01 19:56:46 +00: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-06 23:24:59 +00:00
|
|
|
void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad, int idx)
|
1998-12-21 10:56:39 +00:00
|
|
|
{
|
2015-04-24 20:33:34 +00:00
|
|
|
if (ad->sk == NULL || idx >= sk_void_num(ad->sk))
|
|
|
|
|
return NULL;
|
|
|
|
|
return sk_void_value(ad->sk, idx);
|
1998-12-21 10:56:39 +00:00
|
|
|
}
|
2019-05-01 10:02:43 +00:00
|
|
|
|
2021-02-24 08:07:52 +00:00
|
|
|
OSSL_LIB_CTX *ossl_crypto_ex_data_get_ossl_lib_ctx(const CRYPTO_EX_DATA *ad)
|
2019-05-01 10:02:43 +00:00
|
|
|
{
|
|
|
|
|
return ad->ctx;
|
|
|
|
|
}
|
