Hi Jeffrey, > Come to think of it, maybe OpenSSL should simply perform a call to > RAND_poll() as part of the DLL initialization. This would solve many problems.
No, it would create some. RAND_poll() calls LoadLibrary() which is a no-no from DllMain(). malloc() is not safe to call from DllMain() when the C Runtime is being dynamically linked in, and since RAND_poll() is so complex it is possible that malloc() is being called or will be in the future without anyone realising it's a no-no. However, I know where you're going with this, and I agree that it's something that needs addressing. It's a general problem that has been troubling me on another project. I don't know that I have the greatest solution, but I'll do a quick dump of some of the options here. 1. It is safe to create/initialise synchronization objects (ie. a mutex) in DllMain() for DLL_PROCESS_ATTACH. A single master OpenSSL mutex could be created to be used for on-demand (first-access) initialisation of subsystems. I don't recall the equivalent DLL entry point on Unix platforms or it's semantics, but as an aside does anyone know if such entry points are standard across all Unix implementations that support threading? 2. Alternatively, each subsystem could use it's own init-on-lock mutex (a la PTHREAD_MUTEX_INITIALIZER) but such a primitive might not be supported on all platforms and would introduce tighter coupling which is counter to OpenSSL's thread library agnostic approach. 3. Point 1 does not address the situation where OpenSSL is built as a static library and included in some other DLL (and the FIPS support may require this to be the standard setup for many projects). It would be the responsibility of the wrapping DLL to call whatever OpenSSL function initialises the master mutex from it's own DllMain(). This can get hairy when the static library using OpenSSL is also provided as a static library -- the responsibility has to be carried carefully up the chain. 4. In it's most basic form (OpenSSL as a DLL) Point 1 bypasses the thread library agnostic approach that OpenSSL uses because there is no way for the user to first setup the mutex initialisation callbacks. I can't think of a good solution to this. Creating a wrapping DLL who's DllMain() sets up the callbacks and then calls the OpenSSL master mutex initialisation function would work, but then the ability for the caller of that DLL to customise the mutex functions has been lost. Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, 13 July 2004 11:14 PM To: [EMAIL PROTECTED] Subject: Re: possibly bug in crypto/rand/rand_win.c Suggestion: This is a usage error. Be sure to initialize openssl when your application starts or when your DLL is loaded. Do not wait for the first thread to attempt to make a call to OpenSSL to initialize it. Come to think of it, maybe OpenSSL should simply perform a call to RAND_poll() as part of the DLL initialization. This would solve many problems. Jeffrey Altman Jiang Lei wrote: > Hi, > > Sorry if this message is sent twice. > > I got problem running RAND_poll() in multi-threaded programs. The > function sometimes crashes at "heap_next(&hentry)": > > > ... > if (heaplist_first(handle, &hlist)) > do > { > RAND_add(&hlist, hlist.dwSize, 3); > hentry.dwSize = sizeof(HEAPENTRY32); > if (heap_first(&hentry, > hlist.th32ProcessID, > hlist.th32HeapID)) > { > int entrycnt = 80; > do > > RAND_add(&hentry, hentry.dwSize, 5); > while (heap_next(&hentry) > ^^^^^^^^^^^^^^^^^^^^^^^^^ > *** this is where the problem is *** > && --entrycnt > 0); > > } > } while (heaplist_next(handle, > &hlist)); > ... > > An article at > http://www.codeproject.com/threads/Thelp32ReadProcessMemory.asp > revealed that the function "Heap32Next" is not appropriate to be used in threaded > programs: > > [QUOTE START] > > The "snapshot" > > The toolhelp functions make use of a snapshot to access process, > thread, module, and heap lists in the system. To quote MSDN: > > "The lists in system memory change when processes are started and > ended, threads are created and destroyed, executable modules are > loaded and unloaded from system memory, and heaps are created and > destroyed. The use of information from a snapshot prevents > inconsistencies. Otherwise, changes to a list could possibly cause a > thread to incorrectly traverse the list or cause an access violation > (a GP fault). For example, if an application traverses the thread > list while other threads are created or terminated, information that > the application is using to traverse the thread list might become > outdated and could cause an error for the application traversing the > list." > > [QUOTE END] > > I guess that tells why. The most simple resolution will be to remove > the Heap32Next.(of course > this will trade off rand seed quality, too). > > Any ideas? > > > regards > > Lei > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
