When loader.c is used to load a shared library, and that attempt to load it fails FOR ANY REASON, NSS_Init fails and PR_GetError returns SEC_ERROR_IO. So, the user of the program gets a useless "IO" error instead of one that identifies failure to dynamically load a shared library. I believe the solution to this involves changes to the error mapping/handling in PK11wrap, and perhaps also in softoken.
It requires adding PKCS #11 error codes. Any error that is generated outside of the data passed to a PKCS #11 module currently falls in one of the following cases: CKR_GENERAL_ERROR CKR_DEVICE_ERROR (this is error softoken currently uses whenever it has difficulty with either the database layer or the freebl layer, as these are the instantiation of our 'device' ). CKR_HOST_MEMORY CKR_DEVICE_MEMORY I believe both General error and Device error are mapped to SEC_ERROR_IO (I know the former is). We have added some vendor defined ERROR codes to handle database open failures. We can probably do that for this case as well.
Yes, CKR_DEVICE_ERROR is mapped to SEC_ERROR_IO explicitly, and CKR_GENERAL_ERROR is also mapped to SEC_ERROR_IO (the default error returned by PK11_MapError). With my patch (attachment 346581 [details] [diff] [review]) in bug 453364, CKR_DEVICE_ERROR will be mapped to SEC_ERROR_PKCS11_DEVICE_ERROR, and CKR_GENERAL_ERROR will be mapped to SEC_ERROR_PKCS11_GENERAL_ERROR. These new error codes will be a minor improvement over SEC_ERROR_IO. We should add a vendor-defined CKR_NSS_LIBRARY_LOAD_FAILED and map PR_LOAD_LIBRARY_ERROR to and from it. Since other Cryotoki libraries may also need to load shared libraries, we should propose a new CKR_LIBRARY_LOAD_FAILED error code for PKCS #11 v2.30.
> I believe both General error and Device error are mapped to SEC_ERROR_IO Yes, and that's the problem. SEC_ERROR_IO is inappropriate for those in general. I'd also suggest that we need smarter error mapping in PK11wrap, similar to the error mapping in NSPR. NSPR has one function that does the default mapping of OS error codes to NSPR errors, but it doesn't use that exclusively. Many NSPR functions have their own error mapping functions that map errors that have specific meaning in the context of that function. That's what we need here, the ability to apply specific NSS error codes to PKCS#11 CRV values that interpret them in context. For example, CKR_DEVICE_ERROR from C_Initialize should be reported as a different NSS/NSPR error code than CKR_DEVICE_ERROR from (say) C_Encrypt.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.