As came out in discussions on the openssl-users list, this problem
appears to be restricted to a specific use case.  When RAND_poll() is
called from within the init routine of a DLL.  The attempt to query
the HKPD\Global key results in a series of function calls being made
to various COM objects.  However, this requires a forced call to
CoInitializeEx.  

>From microsoft's documentation:

"Because there is no way to control the order in which in-process
servers are loaded or unloaded, it is not safe to call CoInitialize,
CoInitializeEx, or CoUninitialize from the DllMain function."

This implies that using Performance Data is not safe during DLL
initialization.  We have seen problems with use of Performance Data in
the past on other Windows systems.  It is a valuable tool for
retrieving entropy. 

A reading of the warning text describing the use of DllMain follows:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/dll_8asu.asp

"Warning  On attach, the body of your DLL entry-point function should
perform only simple initialization tasks, such as setting up thread
local storage (TLS), creating objects, and opening files. You must not
call LoadLibrary in the entry-point function, because you may create
dependency loops in the DLL load order. This can result in a DLL being
used before the system has executed its initialization
code. Similarly, you must not call the FreeLibrary function in the
entry-point function on detach, because this can result in a DLL being
used after the system has executed its termination code. 

"Calling functions other than TLS, object-creation, and file functions
may result in problems that are difficult to diagnose. For example,
calling User, Shell, COM, RPC, and Windows Sockets functions (or any
functions that call these functions) can cause access violation
errors, because their DLLs call LoadLibrary to load other system
components. While it is acceptable to create synchronization objects
in DllMain, you should not perform synchronization in DllMain (or a
function called by DllMain) because all calls to DllMain are
serialized. Waiting on synchronization objects in DllMain can cause a
deadlock. 

"To provide more complex initialization, create an initialization
routine for the DLL. You can require applications to call the
initialization routine before calling any other routines in the
DLL. Otherwise, you can have the initialization routine create a named
mutex, and have each routine in the DLL call the initialization
routine if the mutex does not exist."

Since this precludes the use of almost all functions which could be
used to collect entropy it seems fairly clear that the man page for
RAND_poll() should be modified to note that it should not be called
during DLL initialization.  The recommendations described in the last
paragraph describing the use of named mutex and DLL specific
initialization function should be followed.

- Jeffrey Altman



> 
> 
> We use a static initializer in our dynamic library to seed openssl's
> PRNG by calling RAND_screen on Windows.  We've noticed curious behavior
> on WINNT 4.0 where RAND_poll hangs on the Windows registry function,
> RegQueryValueEx, when trying to extract performance behavior.
> 
> There is a documented bug with the ANSI version of RegQueryValueEx (KB
> Q226371) and they suggest
> using the UNICODE version of it directly, yet it still hangs even with
> that version. 
> 
> For the time being, we removed the section where it polls the
> performance data entirely and that works.
> 
> For the record, we're using OpenSSL 0.9.6c, WINNT 4.0 with MSVC++ 6.
> 
> 
> Thanks,
> Jerry Napoli
> [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [EMAIL PROTECTED]
> Automated List Manager                           [EMAIL PROTECTED]
> 



 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 available now!!!
 The Kermit Project @ Columbia University   includes Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 [EMAIL PROTECTED]                OpenSSL. Interfaces with OpenSSH
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to