Redhat 8.0 using modutil v3.7.1 from either CMS 6.1 or NES 6.1sp2: I can't add the Chrysalis LunaSA PKCS#11 security module on Linux. The same appliance can successfully be added on Solaris, though. from the vendor's investigations: Bill, Our Logging library reports an error on the call to C_Initialize. This call ussually has a NULL_PTR parameter passed into it. Can you ask your NSS engineers if they are doing anything different with the C_Initialize call on Linux, and if they could send us an example of how they make this call? Regards, Mark
Bob, are we passing a non-NULL argument to C_Initialize of other vendors' modules? Bill, I believe a module should ignore a non-NULL argument to C_Initialize if it doesn't understand it. Bob, is that the right action to take according to PKCS #11?
Sigh, I'm not sure something is missing in the translation of the error report, so I am going to make some assumptions about what the report paragraph really means. I am going to assume they mean the argument to C_Initilize is not a NULL_PTR, not the RESERVED arguement to the initialization structure that is supposed to be passed to C_Initialize. PKCS #11 2.1 and later specified the structure that is optionally passed to C_Initialize. This parameter specifies application requirements for multi-threading. NSS always passes this parameter to tokens at initialization time. If the token cannot handle threading, or doesn't recognize this parameter, is returns and error, then NSS will then call C_Initialize with NULL, and turn of threading for this particular token. So there are a couple of things that I see that are fishy about this report. First, this behavior is the same on all platforms, including Solaris. Tokens which do not understand threading will return an error and then NSS will initialize with the NULL parameter, so these tokens should work correctly (unless there is a problem where the first Initialize call leaves the token in some funny state where it can't pass the second, but this would be a token problem). The second fishy thing is that it surprises me that the LunaSA token does not recognize this parameter, since threading is critical to any hardware accellerator performance. I know of no other vendor that does not recognize this parameter. As for the answer to Wan-Teh's question, no that is not the correct behavior. Tokens are expected to check that the parameter is NULL and return an error if it is. This signals the application that the token does not know how to do function xyz (in this case threading), and allows the application to initialize the token in non-threaded mode (NSS locks all access to the token to prevent race conditions inside the token code itself. If my assumption above was wrong, please let me know and I'll adjust my reponse appropriately.
Do we have an update from the vendor on this with more information based on my previous response?
Chrysalis had a compiler flag error when building the Linux drivers. they've since fixed their compiler problems and the new drivers work correctly with modutil now. I'm not sure about the NULL parameter issue, I don't think it's relevant anymore. In this case, the third-party vendor provided a fix so this bug can be marked INVALID.
Marking invalid per shadow's comment above.
Testing ability to access bugzilla from Chrysalis-its.... no action needed.