464411 - NSS reports SEC_ERROR_IO when loader.c cannot load a shared lib

Status: RESOLVED INCOMPLETE

(NSS :: Libraries, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[Robert Relyea]

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.

Comment 2

[Wan-Teh Chang]

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.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

> 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.