Hi, * Richard Levitte - VMS Whacker ([EMAIL PROTECTED]) wrote: > The CHIL interface was once meant as some kind of general purpose > library to access certain functions in a cipher box or smart card. > For that reason, it asks for mutex callbacks exactly like OpenSSL > does (and probably for the same reasons).
Ah, well now it's starting to get complex. The same argument can be made that chil should then push this problem onto its "tokens" if indeed it is just a general interface. Ie. sooner or later, you hit crypto implementations and stateful logic that needs locking - IMHO the argument still applies that *this* code is highly architecture-specific and so could and perhaps should handle exclusive locking if it needs it and none is provided "from above". > Or we could apply what you just said to OpenSSL and ask why OpenSSL > can't provide built-in threading support so the application authors > don't have to deal with it. Are you willing to do that work? I'm not > sure I am. Not really - OpenSSL is an abstract library, providing reusable components for a variety of platforms, application models, and (via wrappers) even languages. The idea of applications providing threading support is good - if the application wants it, and knows what kind it wants, it can hook openssl and force it to use it. A bad OpenSSL would implement locks and other threading semantics irrespective of the application. On the other hand, crypto hardware that uses a local daemon process via unix domain sockets and asynchronous comms already knows a lot about its target platform, crypto architecture, and environment. Moreover, IIRC, the issue is what to do if a threaded application is using this functionality but doesn't provide threading support? The obvious response I think we all agree on is: fix the application (apache2). However, if the hardware support wants to be robust against this even in the face of insufficient application use of the API, it should implement fallback locking into its own model. Async/sockets/service code could easily handle this in one way, and other crypto architectures (eg. libs/ioctl) could probably find other mechanisms more to their liking. OpenSSL isn't the place to implement those "we know the platform and requirements" fallbacks, and *if* chil is some kind of general interface to lower-level things, then "chil" isn't the place either. But sooner or later, if you keep drilling, you find something that is :-) > That said, I did believe that libhwcrhk would provide builtin > threading support on at least some systems, but I may recall > incorrectly. It would make sense for it to do so - otherwise the conclusions are fairly simple; if you need threaded applications to provide threading support hooks and they do not, you're screwed. IMHO the most logical change for OpenSSL is to revamp the locking in a future version - the static vs dynamic stuff is already a little too inconsistent, and both don't really offer much room to implement clever locking schemes at all. However, for 'chil' and 0.9.7, the issue seems to be more with Apache2. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
