Remove CKF_LIBRARY_CANT_CREATE_OS_THREADS

NEW
Assigned to

Status

NSS
Libraries
10 years ago
6 years ago

People

(Reporter: Wan-Teh Chang, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

10 years ago
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?

Comment 1

10 years ago
-- 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.  

Comment 3

10 years ago
It's not a new situation for me... It seems that the cryptoki mailing list often drops my responses (at least bugzilla preserves them:).

(Assignee)

Comment 4

10 years ago
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.  

Comment 6

6 years ago
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://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/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?
(Assignee)

Comment 7

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.