Barry Moore wrote,
> Anyone there have an idea as to when the new 0.9.6h release will
> occur ?
>
> We need to build a kit that includes the "race condition" fixes
> implemented several weeks ago, but I can't see any "chatter" as to
> when the official release will be.
Thanks for pointing me at this patch.
Looking at it tho', there's still a couple of problems. Here's one
example of the first one,
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
memcpy((char *)&SSLv23_client_data,
(char *)sslv23_base_method(),sizeof(SSL_METHOD));
SSLv23_client_data.ssl_connect=ssl23_connect;
SSLv23_client_data.get_ssl_method=ssl23_get_client_method;
init=0;
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
There needs to be a second check of init *inside* the critical section,
ie.,
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
memcpy((char *)&SSLv23_client_data,
(char *)sslv23_base_method(),sizeof(SSL_METHOD));
SSLv23_client_data.ssl_connect=ssl23_connect;
SSLv23_client_data.get_ssl_method=ssl23_get_client_method;
init=0;
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
Here's why: suppose we have two threads racing; both see init != 0, so
they both enter the conditional; one will enter the critical section
first; but once it leaves the second thread will acquire the lock and
execute the initialization code a second time. Adding the second check
within the scope of the lock prevents the the double initialization
(well, not necessarily, see below). This is the "double checked
locking" pattern, see,
http://www.cs.wustl.edu/~schmidt/editorial-3.html
It doesn't actually look as tho' a double initialization is going to do
any real harm here, but even so ... there are lots of apparently
innocuous changes to the initialization code which could make a double
initialization dangerous.
Unfortunately there's more, because there's no guarantee that this fixes
things on all processor architectures, especially (tho' not
exclusively) with SMP machines. Depending on the underlying memory
model there are varying guarantees about when writes from one thread
are visible to reads from another. Marking init as volatile might help,
but isn't guaranteed to. Strictly speaking you need to insert processor
specific read and write memory barrier instructions to be absolutely
sure that all threads have a consistent view of the value of init.
I know Doug Schmidt wrote an article that went into all the gory
details, but I can't lay my hands on it right now. Googling for
something like,
double checked locking memory barrier pthread
will probably pull up something useful.
An alternative might be simply to use pthread_once and pray that the
platforms' implementation is correct (I suspect that in quite a few
cases it's not).
Cheers,
Miles
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
