Mark Phalan wrote:
On 29 Mar 2010, at 20:20, David Schwartz <dav...@webmaster.com> wrote:
Will existing libraries continue to
not set the locking callbacks and fail horribly if the system OpenSSL
isn't
compiled with this flag?
Or will they set sane locking callbacks to be safe
-- making this fix a no-op?
Even without the proposed change libraries should at least check before
clobbering the existing callbacks. Checking before setting will be racy
but still better than blindly replacing callbacks.
The proposal doesn't make anything worse it 1) removes the race if
libraries set the callbacks properly and 2) fixes MT issues if they don't.
Of course there is always the problem of what happens on dlclose() of
the lib if the callbacks are set...
Having thought about the problem a little more.
There is no reason for it to be racy if you make use of the locking
implementation either already set or being passed. One thing for sure
there is some kind of valid locking mechanism to use, so make use of the
first available lock id slot for the purpose of managing the getting and
setting of the locking mechanism in a re-entrant thread-safe manner.
There should also be a reference counting mechanism, so any users who
set the locking up should also unset the locking via reference counting.
I agree that the concept of stacking and restoring the locking
mechanism (that has been suggested) is bogus and can not work but the
concept of the "first users wins" can work.
The first user to setup should get an indication back that it is so.
The last user to unset should get an indication back that is it so.
There needs to be a test, test-and-set and set operations on the locking
that are individually atomic and re-entrant thread-safe. (by making use
of the locking mechanism setup). There is no need for the 'test' and
'set' operations to be separate from the 'test-and-set' since one API
call can achieve all purposes, just like Unix signal handler setup
sigaction(2) does inside the kernel.
There should be an OpenSSL provided API call that sets up the locking to
a default implementation for the platform, or else it returns an error
return indicating OpenSSL was not compiled with any default
implementation (for your platform) which would force the caller to
address this matter within their own platform. Addressing it can be
done via patching future versions of OpenSSL or to provide their own
from their application.
I disagree that it is a bad idea to think about it now. Yes the horse
has bolted in respect of the number of application out there which are
open to the risk of failure due to this. So with that in mind there is
no reason not to consider what the correct future proof solution is even
if that means API breakage to force all applications to reconsider this
problem and bully them into consensus that the OpenSSL provided solution
will be good enough for most.
This means symbol changes and clear documentation on how to transition
with example code to make the application maintainers job easier. Make
the solution an easy 15 minute exercise to understand and read up about
and then modify their code base and I'm sure you can win the hearts and
minds of those using OpenSSL that it was a matter that needed to be
address with a small amount of breakage.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
