NSS error handling

[Graham Leggett]

Hi all,

I am trying to call PK11_CreateContextBySymKey and it is returning NULL.

I understand that if I called the PORT_GetError function, I would get
the error that occurred, but that is still of no use as it is just a number.

I found a function called SECU_Strerror that seems to be used to
translate error codes into a form understandable by humans, but this
function is not defined in any of the NSS public header files.

What is the canonical way that errors should be handled in NSS?

Is there a document that describes this?

Regards,
Graham
--


_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto

[Graham Leggett]

Graham Leggett wrote:

> I am trying to call PK11_CreateContextBySymKey and it is returning NULL.

Using PORT_GetError, the error code returned is zero.

Reverse engineering the PK11_CreateContextBySymKey function, I have
found that the function returns NULL in a number of locations, many
without any attempt to set an error code, which effectively means it is
impossible to distinguish one error from another.

 From the debugger trace below, is there any obvious reason why the
above function should return null?

253        cipherMech = CKM_DES3_CBC_PAD;
(gdb)
254        break;
(gdb)
271    keyItem.data = (unsigned char*)key;
(gdb)
272    keyItem.len = keyLen;
(gdb)
274    PK11SlotInfo * slot = PK11_GetBestSlot(cipherMech, NULL);
(gdb)
277    block->key = PK11_ImportSymKey(slot,
(gdb) print slot
$1 = (PK11SlotInfo *) 0x812600
(gdb) next
285    if (slot) {
(gdb) print block->key
$2 = (PK11SymKey *) 0x310f20
(gdb) next
286        PK11_FreeSlot(slot);
(gdb)
289    switch (type) {
(gdb)
294        if (mode == MODE_CBC) {
(gdb) print block->key
$3 = (PK11SymKey *) 0x310f20
(gdb) next
326            block->ctx = PK11_CreateContextBySymKey(CKM_DES3_ECB,
CKA_ENCRYPT, block->key, NULL);
(gdb)
327            block->ivSize = 0;
(gdb) print block->ctx
$4 = (PK11Context *) 0x0
^^^^^^^^^^^^^^^^^^^^^^^^ context returned is NULL
(gdb) next
386    perr = PORT_GetError();
(gdb)
387    if (perr) {
(gdb) print perr
$5 = 0
^^^^^^ error returned is zero

Regards,
Graham
--


_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto

[Nelson B Bolyard]

Graham Leggett wrote, On 2008-09-02 12:49:
> Graham Leggett wrote:
>
>> I am trying to call PK11_CreateContextBySymKey and it is returning NULL.
>
> Using PORT_GetError, the error code returned is zero.

Please file a bug in bugzilla.mozilla.org about that.
Product: NSS
Component: Libraries
Version: whatever version you're using

> Reverse engineering the PK11_CreateContextBySymKey function, I have
> found that the function returns NULL in a number of locations, many
> without any attempt to set an error code, which effectively means it is
> impossible to distinguish one error from another.

Well, NSS's rule is that the lowest level function (the first function)
called that finds a problem and returns a failure result (NULL, or
SECFailure) MUST set the error code.  Higher level functions (callers of
the function that first finds the problem) may leave the error code alone
(leave it set to the value set by the first function to find the problem).

So, if you see code in an NSS function that calls another ("inner") NSS
function, and detects that that inner function has returned a failure
indicator, and then returns without setting an error code, that's expected.
For example, NSS's "PORT" allocation functions all set error codes on
failure so callers of those PORT allocation functions seldom set error
codes when they detect an allocation failure.

On the other hand, if you see code that detects a problem itself, e.g.
by finding a null argument, or finding a null pointer in a structure,
and returns a failure result without setting an error code, that's a bug.

I take all those bugs seriously and make fixing them a pretty high priority.
As a reviewer, I try not to allow a patch to be committed that makes that
mistake.  But I'm not the only NSS reviewer, and mistakes happen.

> From the debugger trace below, is there any obvious reason why the
> above function should return null?

Not immediately obvious.
Here are some questions that may help identify the cause.

What was the value of keyItem.len ?

Are you using any PKCS#11 modules besides NSS's own modules?

Do you possibly have a module marked as preferred ("default") for 3DES
that doesn't actually do 3DES?

If you were using only NSS's PKCS#11 modules, did you have the Softoken
module in "FIPS mode" ?
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto

[Graham Leggett]

Nelson B Bolyard wrote:

> Please file a bug in bugzilla.mozilla.org about that.
> Product: NSS
> Component: Libraries
> Version: whatever version you're using

I just added the bug here:

https://bugzilla.mozilla.org/show_bug.cgi?id=453364

The gdb trace of how I got there is included, along with the key
variable values along the way.

> Not immediately obvious.
> Here are some questions that may help identify the cause.
>
> What was the value of keyItem.len ?

24 (corresponding to the 192 bit cipher).

> Are you using any PKCS#11 modules besides NSS's own modules?

Not that I am aware of.

> Do you possibly have a module marked as preferred ("default") for 3DES
> that doesn't actually do 3DES?
>
> If you were using only NSS's PKCS#11 modules, did you have the Softoken
> module in "FIPS mode" ?

The module is initialised as follows:

s = NSS_NoDB_Init(NULL);

The code is a test case, and doesn't do anything else other than encrypt
a string, and then try and decrypt the same string.

Changing the encryption mode from MODE_ECB to MODE_CBC, causes the
PK11_CreateContextBySymKey function to succeed.

The next function PK11_CipherOp then fails, with the error code "-8192".

This error code isn't recognised by PR_ErrorToName(), and so again, no
action can be taken.

Should I log this as a separate bug, or does this error code -8192 have
some meaning to NSS?

Regards,
Graham
--


_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto

[Nelson B Bolyard]

Graham Leggett wrote, On 2008-09-02 14:59:

> I just added the bug here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=453364

Thanks.

> Changing the encryption mode from MODE_ECB to MODE_CBC, causes the
> PK11_CreateContextBySymKey function to succeed.

That's a big clue.  I can think of two issues:

1) Your code asks NSS to find a slot that supports CBC, then imports the
key into that slot, specifying that it is to be used with some crypto
mechanism that you didn't show (might have been CBC or ECB), but then
when you actually use the key, you use it with ECB, which is a different
mechanism than the one you specified when you asked for a slot.

2) Since ECB is never used in any of the standardized (IETF) protocols
implemented in NSS, I wouldn't be shocked to find that there's a problem
with 3DES ECB.  But before concluding that, I'd want to see the test be
sure to use the same mechanism in all calls, as mentioned above.

BTW, please add a comment to the bug specifying which mechanism your code
passed to PK11_ImportSymKey.  That will aid in reproducing what you saw.

> The next function PK11_CipherOp then fails, with the error code "-8192".
>
> This error code isn't recognised by PR_ErrorToName(), and so again, no
> action can be taken.

That's right, not with PR_ErrorToName.

> Should I log this as a separate bug,

No, because it's not a bug.  NSS's shared libraries have never offered any
functions that translate error numbers into strings.  The reason is that
no two operating systems or applications use the same technique for
localizing strings.  Any method that NSS chose to use would be wrong for
all (or perhaps all but one) applications.  PR_ErrorToName is a great idea
IMO, but no Mozilla applications (not even Firefox) use it.  There is an
RFE, asking NSS to supply strings to PR_ErrorToName, but because of the
localization issue, it's not a high priority.

> or does this error code -8192 have some meaning to NSS?

You will find a web page describing the error strings for many error codes
at http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html

There are 3 header files that contain macro invocations that can be used,
together with your own macro definitions, to put error string into your
program.  Find those 3 header files at
<http://mxr.mozilla.org/security/find?text=&kind=text&string=nss%2Fcmd%2Flib%2F.*errs.h>

Find an example of a function that uses those header files with its own
macro at
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/cmd/lib/secerror.c&rev=1.3&mark=54-56#38>

_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@...
https://lists.mozilla.org/listinfo/dev-tech-crypto