Right now NSS uses both the CKF_LIBRARY_CANT_CREATE_OS_THREADS and CKF_OS_LOCKING_OK flags when loading a PKCS #11 module: http://lxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11load.c#84 If we don't have a good reason to use CKF_LIBRARY_CANT_CREATE_OS_THREADS, I suggest that we remove it. Bob, what do you think?
-- This is an exact copy of the text of my reply to the Cryptoki mailing list here the issue was first raised ---- The purpose of CKF_LIBRARY_CANT_CREATE_OS_THREADS come from the days when many 'popular' operating systems did not support a system thread package. Some packages, like NSPR (which NSS was based on) had their own completely independent thread implementation. If the PKCS #11 module did not use that thread implementation. Since the thread locking calls only supplied lock primitives, not thread creation primitives, then there was not way for the library to properly manage any threads created by a competing thread package. I think that mismatch has pretty much disappeared now. NSPR uses the OS supplied threads and it's underlying thread package in all of this supported platforms that I know of (certainly on all the platforms I have products on). The only possible exception I can think of is a mismatch between Windows threads and NT Fibers. (Traditionally NSPR Win95 versus NSPR WinNT). The only products I can think of that uses Fibers instead of threads would be Window server products based on NSS, and I think the only supplier of those would be Sun. Nelson would have to answer if that's still the case. Wan-Teh, is there a problem if a PKCS #11 module internally creates a thread, but we try to use the fiber locks to protect it? (Is this even an issue if the thread is completely internal to the PKCS #11 module?).
Bob, I have bad news for you. The cryptoki mailing list is having problems. A number of long-time subscribers are now in the position where the messages they send to the list are silently dropped. Laszlo Elteto was one, and now it appears that you are one also.
It's not a new situation for me... It seems that the cryptoki mailing list often drops my responses (at least bugzilla preserves them:).
If a PKCS #11 module internally creates a native thread, and the thread calls PR_Lock() via our LockMutex callback, the thread will be attached to NSPR on the first call, and everything will just work. This is why I think NSS doesn't need to use CKF_LIBRARY_CANT_CREATE_OS_THREADS. It is the CKF_OS_LOCKING_OK flag that could be problematic with the "WINNT" version of NSPR. If a PKCS #11 module uses OS locking directly and doesn't use our mutex callbacks, and an NSPR local thread (an NT fiber) calls into the module, the OS locking function will block all the NSPR local threads (fibers) running on the underlying native thread. I seem to remember that NES (Netscape Enterprise Server, the predecessor of Sun Java System Web Server) used only native threads to call into third-party crypto modules to deal with this issue.
All Sun server products that run on Windows use the NT flavor of NSPR. Also, there are products that use NSS+NSPR and run as plugins to IIS (yes, IIS) and they use the NT flavor of NSPR too. I don't know what kinds of threads IIS uses.
I randomly discovered this issue while looking at a PKCS#11 module that interfaces with OS X's Security.framework (note: not low-level CDSA/CSSM side, but the high-level SecKeyRef-et-al). Security.framework provides a way for an application to be notified when a Keychain changes (such as a user inserting or removing a smart card, as viewed by the OS, but also when certificates are added/removed or trust settings changed). My intent was to use these notifications to simulate a token insertion/removal (I can't use slot additional/removal because NSS uses PKCS#11 2.20, not the 2.30 drafts - http://email@example.com/msg05516.html ). Such callbacks require a Core Foundation run loop being active, which is best/safely accomodated by having the PKCS#11 module spawn a new native thread that can run a CFRunLoop monitoring for these events. Because NSS passes CKF_LIBRARY_CANT_CREATE_OS_THREADS, it's not "correct" to do that. Because I fully control the interaction between NSS and the module, it seems I could "safely" ignore that flag. However, based on the discussion here, it seems correct here just to remove it entirely. Given that it's been 4 years and a day since the last activity on this, is there any objection to removing this flag now?
I think we can remove CKF_LIBRARY_CANT_CREATE_OS_THREADS. As I responded in comment 4, the NT fibers used by the "WINNT" build configuration of NSPR should only matter to the CKF_OS_LOCKING_OK flag.