Rene Hollan wrote:
And how, pray tell, should OpenSSL know the threading model the
application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for
OpenSSL to require a "reasonable" threading API to implement SSL data
integrity, and for the application to provide an implementation that
wraps the threading model it uses within that API.
It doesn't need to know the "threading model" in use.
What OpenSSL needs to provide is an "atomic test-and-set" during the
setup of the Threading API calls. For this you are going to have to
provide CPU architecture dependent functions (since you can not rely on
pthread!).
That is the application program when setting up the threading callback
(and therefore "threading model") will have 2 mode of operation:
SET_IF_NOT_SET (in this mode the threading primitives if already setup
would not be overwritten)
SET_ALWAYS (in this mode the threading primitive would always be
overwritten, just like happens now, this mode is not adviable for use
and should not be the default).
The important primitive in this is the "atomic test-and-set" to the
operation to sets up the threading primitives.
Now it is possible for ALL applications out there that use OpenSSL and
already know they are using pthread to wrap up the setting of the thread
callback with pthread mutex calls.
But OpenSSL still needs to expose a variable for all these applications
to synchronize on. All OpenSSL needs to do is expose an exported data
symbol the size of the natural-bitwidth of the architecture.
static atomic_t openssl_threading_synchronization_value;
The example in the OpenSSL documentation need to be updated to explain
how to use pthread and this exposed data variable together to setup a
threading model.
Then all the application that use OpenSSL needs to be FIXED. This last
point some would say is the real headache of the solution and the world
should not be this way.
I am all for someone creating a multi-architecture low level library
that provides a C API to the low level CPU assisted operations. Note
this is not a threading library but a library that exposed
non-privileged CPU assisted operations that the C language does not.
Not limited to but including:
* Atomic read/write/exchange/test-and-set
* Bus lock operations
* Memory barrier operations
* Add/Subtract with/without carry (ever wanted a non-overflowing
addition/subtraction).
* Access to limited instructions that operate on double-natural-bitwidth.
* Instructions that make use of FLAGS register for input/output.
* Full register save/stores (sometimes useful for signals/exception
handling).
In fact I have just such a library already which I maybe presueded to
package up and release. This will cover IA32 (i386/x86_64), Sparc
(v5/v7) and ARM. Both for GCC and the platforms respective native compiler.
For my liking there are starting to be too many issues with OpenSSL in
this modern world. So if the lists petition for change continues to go
unresolved I'm all for seeing a fork created to push though a new policy
(and relinquish control from current incumbents, along the lines of the
EGCS period for GCC). Then let darwinism take its course in the Open
Source way. But this isn't going to happen right now for me.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
