On 03/31/10 01:14 PM, David Schwartz wrote:
Mark Phalan wrote:
Imagine the above case happening in one thread while another thread
makes a similar seemingly innocuous call with a similar effect (dlopen
a
library which uses OpenSSL). What should pkinit and the second library
which uses OpenSSL do? If they set callbacks they'll be racing against
each other. If they don't they will not be MT safe.
The application never sets the callbacks because as far as it's aware
it's only calling POSIX APIs.
If we're talking about existing code, they *must* already set callbacks,
otherwise they're hopelessly broken. Since the setting of callbacks will
unsafely override the set defaults, the suggested fix (to default to
callbacks suitable for the platform's default threading model) actually will
*not* fix this case. If this is the case we care about, why implement a fix
that won't fix this case?
Because it fixes the race when libraries are correctly checking to see
if the callbacks are already set before setting their own. It's a one or
two line change to modify the mis-behaving libraries and new libraries
can take advantage of the new locking.
The purported advantage of this fix is that it solves the "horse has already
left the stable" case where we aren't willing to change the libraries that
call OpenSSL. But it doesn't fix that case.
My reference to the "horse has already left the stable" was referring to
the fact that its not possible to change every library API to include an
API for setting locking callbacks and to change every application to
actually set those callbacks. Sorry if I wasn't clear about that.
I think a one or two line change to a library is something that can be
reasonably done incrementally over time (and something the libraries
should be doing already anyway).
The only way to fix that case that I can think of is for OpenSSL to start
out using callbacks that are safe for the platform's default threading API
and to ignore, but report success, on all attempts to change the locking
callbacks. That may actually be the right behavior for the existing API.
This is something I'd considered but it may end up breaking
applications. I took a quick look at the BIND code and they seem to be
generating statistics from their locking callbacks. This may or may not
be acceptable in the long-term but it certainly would be a large change
with real impact. Removing the ability to set the callbacks will also
mean that using an alternative threading library (for example GNU pth as
someone pointed out) may prove difficult if not impossible.
-M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
