Removed ability to set ex_data impl at runtime. This removed these
three functions:
const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void);
int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i);
int CRYPTO_ex_data_new_class(void);
It is no longer possible to change the ex_data implementation at
runtime. (Luckily those functions were never documented :)
Also removed the ability to add new exdata "classes." We don't believe
this received much (if any) use, since you can't add it to OpenSSL objects,
and there are probably better (native) methods for developers to add
their own extensible data, if they really need that.
Replaced the internal hash table (of per-"class" stacks) with a simple
indexed array. Reserved an index for "app" application.
Each API used to take the lock twice; now it only locks once.
Use local stack storage for function pointers, rather than malloc,
if possible (i.e., number of ex_data items is under a dozen).
Make CRYPTO_EX_DATA_FUNCS opaque/internal.
Also fixes RT3710; index zero is reserved.
Reviewed-by: Richard Levitte <levitte@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
For a local variable:
TYPE *p;
Allocations like this are "risky":
p = OPENSSL_malloc(sizeof(TYPE));
if the type of p changes, and the malloc call isn't updated, you
could get memory corruption. Instead do this:
p = OPENSSL_malloc(sizeof(*p));
Also fixed a few memset() calls that I noticed while doing this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
After the finale, the "real" final part. :) Do a recursive grep with
"-B1 -w [a-zA-Z0-9_]*_free" to see if any of the preceeding lines are
an "if NULL" check that can be removed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Free up bio_err after memory leak data has been printed to it.
In int_free_ex_data if ex_data is NULL there is nothing to free up
so return immediately and don't reallocate it.
Reviewed-by: Tim Hudson <tjh@openssl.org>
The mkstack.pl script now generates the entire safestack.h file.
It generates output that follows the coding style.
Also, removed all instances of the obsolete IMPLEMENT_STACK_OF
macro.
Reviewed-by: Andy Polyakov <appro@openssl.org>
choice but to have to cast away "const" qualifiers from their prototypes.
This does not remove constification restrictions from hash/compare
callbacks, but allows destructor commands to be run over a tables' elements
without bad casts.
Henson). Also, reverse a previous change that used an implicit function
pointer cast rather than an explicit data pointer cast in the STACK cleanup
code.
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.
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages. That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.
This change includes all the name changes needed throughout all C files.
