David Schwartz wrote:
Actually, that wouldn't work. What if you're using a threading library that
permits threads to run in different SMP domains? In that case, the atomic
instructions would only synchronize between threads running in the same SMP
domain.
As I hinted in another post, the less common environments should be the
ones made to customize their OpenSSL implementation to suit their
platform. No one is advocating the removal of the ability to setup and
configure your own bespoke engineering solution to support threading on
your platform.
In order for an application to work in these rare use cases there must
already be some amount of kludge away from the more common model (how
many multi-threaded applications work out of the box on your cited
platform ?). OpenSSL can still work for them just like it does now.
A question for you, are you stating an unmodified OpenSSL is being used
to your knowledge on the kind of platform you are suggesting ? Since my
understanding of OpenSSL is that it will not work in a non-symmetric
memory system unmodified.
OpenSSL's alloc/free must consistently allocate memory mapped at the
same virtual address space that is mapped and visible across every
thread that uses OpenSSL (maybe I have over generalized here). I'm sure
such systems have provisions for mappings and arena based allocation.
This also means that the OpenSSL DLL shared data sections (.bss, .data
and .rodata) must also meet this requirement.
This also means my proposal to use CPU-atomic operation will work fine,
since the synchronization point comes from memory allocated from .data
DLL section. This point has already been described in a previous post
of mine.
Maybe you have misunderstood my intentions to be "I am seeking to
replace all threading ops with CPU-atomic instructions." LOL! NO I AM
NOT. I am merely proposing the use of a spinlock to protect the
threading model setup and query functions, to provide atomic
test-maybe-set. These functions are used infrequently and usually only
once by whatever subsystem is initializing at the time.
If you can better explain your platform I can better describe how what
is being said here will work for you.
I think you're missing the point that OpenSSL doesn't just support the
typical platform-provided threading libraries. It supports *any* threading
library the compiler can support. There is no guarantee that CPU-atomic
operations are atomic in the same scope as any possible threading library
the compiler can support requires.
I understand your point and nothing being suggested hampers your
continued use of OpenSSL on these exotic platforms. I'm not taking
anything away, just making life easier for a cross-section of users on
common platforms.
Trying to supply the library with atomic operations known safe for the
required atomicity of the threading library in use creates a chicken and egg
problem. You would need atomic operations to specify the atomic operations.
You just need ABI rules (which are already provided by your executable
file format).
You really need to describe in detail how it becomes unsafe so you/I can
point out where your/my thinking has gone wrong.
Fundamentally, OpenSSL is not suitable for direct use a system library. It
requires a wrapper to specify the threading model. (Whether or not this is a
fault in OpenSSL or the people who decided to use it in a way it was not
meant to be used is another question.)
Yes I am all for a libcrypto_r.so as one possible solution. All users
link with this if they want a default threading model to be initialized
before first use.
There are few concerns from my direction to ratify with this solution.
Most of these would be mitigated if threading model setup and support
was moved from the public libcrypto.so to a private API. Which
libcrypto_r.so understood and could manipulate.
This would mean users linking with libcrypto.so would never support
multi-threading as there is no API to do it, so they would have to move
to libcrypto_r.so. However that is a breaking API change, which I guess
means bumping the major DSO version (this is not necessarily related to
the OpenSSL.org release version number).
I agree, the problem in general is not entirely OpenSSL's fault. It is
more of a "dropped ball" between; dynamic linker, platform ABIs and DSO
vendors. Plus the requirement for a wide variety of platform support
with OpenSSL, which means that even if the dynamic linker (or platform
ABI) assistance was available on one platform it would not necessary be
available on another.
This is not an excuse to not have a solution on those platforms that
could have a solution.
And to repeat and clarify the nature of the problem again, "implicit
loading of OpenSSL DSOs, due to being dependent libraries of other
dynamically loaded objects".
The "superior executable program" doesn't use OpenSSL (directly) itself,
but it dynamically loaded at runtime "another.so" which does need to use
OpenSSL. But the "superior executable program" being modular also
loaded at runtime "yetanother.so" and this also implicitly loads OpenSSL
since it also needs it directly. Whose fault was it again ? systemic
failure ? design failure ?
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
