linux: can't add security module with Chrysalis LunaSA HSM



15 years ago
15 years ago


(Reporter: bill, Assigned: Robert Relyea)


Firefox Tracking Flags

(Not tracked)




15 years ago
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:

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?

Comment 1

15 years ago
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?
Assignee: wtc → relyea

Comment 2

15 years ago
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

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

Comment 3

15 years ago
Do we have an update from the vendor on this with more information based on my
previous response?

Comment 4

15 years ago
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
Marking invalid per shadow's comment above.
Last Resolved: 15 years ago
Priority: -- → P2
Resolution: --- → INVALID

Comment 6

15 years ago
Testing ability to access bugzilla from Chrysalis-its.... no action needed.
You need to log in before you can comment on or make changes to this bug.