297734 - root cert module does not support OS locking mode

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

I found that the NSS root cert PKCS#11 module does not support initialization
with  CK_C_INITIALIZE_ARGS containing NULL pointers to lock functions, and the 
CKF_OS_LOCKING_OK flag set .

This needs to be fixed in order for bug 292809 to be resolved .

Comment 1

[Julien Pierre]

I started implementing a patch, which makes libnssckfw.a use NSPR functions
directly, essentially deleting most of nsprstub.c .
But libnssckbi.so is linked with libnssbase.a, which uses many NSPR functions .
Instead of calling the stub implementations, they will now call the real NSPR
functions. This would violate case #3 for C_Initialize - when the caller
provides the lock and does not set CKF_OS_LOCKING_OK , ie. the same problem that
softoken has (see 297735)  .

I'm not crazy about fixing case #2 and breaking case #3 at the same time. We
should figure out a solution to make both work, at least for the root cert
module . One of them would be to recompile libnssbase to use stub functions
instead of calling the NSPR functions directly when linking it to the root cert
module. 

Comment 2

[Wan-Teh Chang]

Julien, you can implement the four Mutex callbacks that
use OS locks in libnssckfw.a.  This solutions avoids linking
libnssckfw.a with NSPR.  The four mutex callbacks are small so
the code duplication with NSPR is small.

Comment 3

[Julien Pierre]

Wan-Teh,

I can appreciate that it's only 4 functions, but the platform-specific code
would have to be included for all of them right into the ckfw source . NSPR
supports a lot of platforms. It seems like doing it this way would be a
maintenance burden for NSS going forward .

I was thinking of perhaps dynamically loading the PR_Lock / PR_Unlock /
PR_NewLock / PR_DestroyLock symbols from nssckfw when they are needed . But this
also requires dlopen / dlsym / dlclose equivalents . It's still 3
platform-specific functions to implement . But perhaps these are less variable
accross platform than the lock functions ?

One solution might be to include the body of code for PR_LoadLibrary /
PR_FreeLibrary / PR_FindSymbol in an NSPR header file (with an optional macro
defined), so that NSS could include it, rather than duplicate it. I wouldn't
suggest that we do this for the lock functions of course, only for those 3
symbols . This could also be useful for other libraries that don't want to
implicitly depend on the NSPR DSOs . Thoughts ?

Comment 4

[Wan-Teh Chang]

The OS locking code only has a few possible implementations.
pthread mutex covers all Unix/Linux platforms and Mac OS X.
Adding Windows will achieve your goal in practice.  Adding
OS/2 and BeOS will achieve complete platform coverage.

Comment 5

[Wan-Teh Chang]

We plan to fix this bug as a by-product of fixing bug 302416.
We will link the root cert module with NSPR shared/dynamic
libraries and make it support only single-threaded mode and
OS locking mode.

See bug 302416 comment 26.

Comment 6

[Wan-Teh Chang]

Fixed as a by-product of fixing bug 302416.