At 01:15 AM 12/5/02 +0100, Richard Levitte via RT wrote: > >[[EMAIL PROTECTED] - Wed Dec 4 12:08:18 2002]: > >> Whilst conducting some testing with OpenSSL 0.9.7beta4 and the nCipher >> chil plugin, I observed the following issues: >> >> 1. Lack of threadsafety if app fails to support new OpenSSL dynamic >> locks >> >> At the moment hw_ncipher.c uses the new OpenSSL dynamic lock code >> inorder >> to implement the hwcrhk locking upcalls. However if the OpenSSL >> application >> fails to implement the dynamic upcalls, i.e. >> CRYPTO_get_dynlock_create_callback() returns NULL, then the hwcrhk >> engine >> code becomes non threadsafe. > >Hmm, that's a good point. However, your solution is not the way to go. >If you take a look at 0.9.8-dev, you'll see that the engines >increasingly become some kind of external module. Therefore, it's not a >good idea to fool the programmers into thinking they can rely on OpenSSL >having the proper static lock for the available engines. > >However, if we can do a good enough assertion (which will not abort(), >just make the engine not load), I can see us doing that. Care to help >in that direction? It'll probably involve using >CRYPTO_get_locking_callback() to see if the application provided any >threading support. If it does that, but hasn't provided any support for >dynamic locks, it's bye-bye engine... Sounds reasonable enough?
I agree completely with your sentiment that multithreaded openssl applications should be required to provide the dynamic locking upcalls. The static locks architectures requires openssl to know how many locks are required at compile time which is not much good for supporting locks in plugins. However if the only effect of an app not supplying dynamic locking upcalls is for the chil engine to fail to load, I don't envisage many app developers getting around to supplying the upcalls. Furthermore it isn't very pleasant for an application to have to supply static locking upcalls as well as the dynamic ones. Would it not be better to break the openssl API in 0.9.7 by removing the static locking upcalls and replacing them with the dynamic ones. This would force the issue and require openssl applications to implement dynamic locks if they are to be multithreaded. Until you do this the openssl core code cannot use dynamic locks internally without the risk of it failing. Bertie ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
