On 06/11/2014 10:24 AM, Peter Waltenberg wrote:
The one we (IBM) hit is composite apps. Multiple independently developed
lumps of code thrown together - someone has to set the locks, but
deciding who is a problem. We deal with it easily as we put a wrapper
around OpenSSL and do it there, but that's not always an option.
The OS installed OpenSSL's should probably also use the OS default
thread model by default for similar reasons.
There were also a number of cases of 'user error' with people just
forgetting to set up the locking around that time.
We face similar issues in Fedora and its downstreams.
For glibc, we have stubs in libc which are always available and are NOPs
in non-threaded problems, so that it might be feasible to set up the
locking primitives by default in libcrypto, without actually linking
with -lpthread.
The latter is important because the presence of the threading library
causes some other libraries to fall back to slower thread-safe variants.
This mostly affects libstdc++ and std::shared_ptr (where atomics are
used for maintaining the reference count), and to a lesser extend,
malloc in glibc itself.
--
Florian Weimer / Red Hat Product Security Team
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
