-----Original Message-----
From: Bodo Moeller [mailto:[EMAIL PROTECTED]]
Subject: Re: mt issue in md_rand.c?
>> I believe that the fix is fairly simple...
>>
>> 1. When setting 'crypto_lock_rand = 1', only do so after setting
>> 'locking_thread = CRYPTO_thread_id()'... This will guarantee that a
thread
>> checking do_not_lock will not see crypto_lock_rand flag set until after
the
>> true locking_thread has been set.
>>
>> // md_rand.c:355 and md_rand.c:520
>> CRYPTO_w_lock(CRYPTO_LOCK_RAND);
>>
>> crypto_lock_rand = 1;
>> locking_thread = CRYPTO_thread_id();
>>
>> would be written like this...
>>
>> CRYPTO_w_lock(CRYPTO_LOCK_RAND);
>>
>> locking_thread = CRYPTO_thread_id();
>> crypto_lock_rand = 1;
>
>This was also my guess when reading your above problem description.
>Hopefully this is a sign that this time it is really correct.
>
>Actually it can not be correct if access to 'unsigned long' values is
>not atomic. If I decide to be that pedantic (and I start to feel I
>should), I have to introduce an additional lock for protecting access
>to 'locking_thread'. This does not add significant overhead as
>this is only needed on the few occasions when 'crypto_lock_rand' is
>set.
You are absolutely correct. I _believe_ that assignment to and retrieval of
data is atomic iff 1) they are properly aligned and 2) less than or equal to
32 bits long (for a 32 bit machine).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
