>       As you can see, this code was modified to work only on NT, since, as
> the comment states, it causes an exception on Windows 2000. It seems,
> however, from our experience, that it causes exceptions on NT as well.
>       Meanwhile, we have removed this code from our build of OpenSSL.
> Probably, this code should be re-evaluated by the author, and, for the
> beginning, removed from the baseline till the solution is found.

It would be very nice if someone with a support contract with
Microsoft could bring the above problem to their attention.

> 2.    The following piece of code seems to have race condition, causing
> very long initialization time for our application, especially when there are
> very many processes and threads running in the system (file:
> crypto/rand/md_rand.c, line: 350):
> 
>       if (!initialized)
>               RAND_poll();
> 
>       CRYPTO_w_lock(CRYPTO_LOCK_RAND);
>       add_do_not_lock = 1;    /* Since we call ssleay_rand_add while in
>                                  this locked state. */
> 
>       initialized = 1;
> 
>       It seems like many threads enter RAND_poll() simultaneously. Here is
> the fix we've made for this:
> 
>       CRYPTO_w_lock(CRYPTO_LOCK_RAND);
>       if (!initialized)
>       {
>               RAND_poll();
>               initialized = 1;
>       }
> 
>       add_do_not_lock = 1;    /* Since we call ssleay_rand_add while in
>                                  this locked state. */
> 
>       Can someone incorporate our fix to the official source?

This fix seems reasonable.

> 3.    In addition, Windows version of RAND_poll() seems to be very slow
> (even when called once per process) when there are very many processes and
> threads (in our tests we have sometimes more than 15000 threads per system).
>       Please, advise what can be done in order to speed-up process
> initialization in this case.

In the kernel section you can put a hard limit on the number of thread
and process blocks which are processed.  Similar to what was done to
limit the number of HEAPENTRYs.

However, I believe the real solution to this problem is to try to make
some estimate of how much entropy we really need instead of
collecting all of the entropy the system can provide to us.  I listed
in the code comments the amount of entropy that each block can be
expected to provide.





 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [EMAIL PROTECTED]          OpenSSL.  SSH soon to follow.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to