add full support to wolfcrypt tests for random.c cryptocbs

[bigbrett]

Description

• Adds a new _ex function for RNG initialization that takes a devid argument and adds return code for better error propagation
• Enables NO_DEV_RANDOM (e.g. bare metal) targets to use a cryptoCb for DRBG seed generation

Testing

Unit tests pass with new additions

[JacobBarthelmeh]

Should this be WOLFSSL_API instead of WOLFSSL_ABI?

[bigbrett]

@JacobBarthelmeh I just used the same function annotation as wc_rng_new, assuming this new function would inherit the same properties as the non-"_ex" version. Note: It is declared as both WOLFSSL_API and WOLFSSL_ABI in the header file.

I see the same pattern used for a few other _ex() functions that we have added (but not all). I assumed we could always add ABI functions, just not subtract. What is the guidance here, would you like me to change it to just WOLFSSL_API?

[JacobBarthelmeh]

Right, once an API is WOLFSSL_ABI for a release it can not be altered. We try to keep public API the same in any event, but WOLFSSL_ABI is binding it. I'd lean towards not adding it to WOLFSSL_ABI until required, but is only a comment not something to hold up this PR if wanting it to start it out as WOLFSSL_ABI.

[douzzer]

I agree with @JacobBarthelmeh that we don't need to be boxing ourselves in on this. For one thing, a minor and useful refactor is possible here to allow nonce to be passed in as a const byte *. If we make it WOLFSSL_ABI we can't do that.

I just did an automated survey of the existing WOLFSSL_ABI functions in wolfCrypt and there's only two _ex() functions in the set, wc_ecc_make_key_ex() and wc_ecc_init_ex(). You can be sure there was some specific reason(s) a customer needed those stabilized.

Btw the total number of WOLFSSL_ABI prototypes in wolfCrypt is just 45, of 1120 WOLFSSL_APIs. In the native TLS layer we currently have 52, of 1711 WOLFSSL_APIs. They're rare birds!

[bigbrett]

Great, I agree on all counts. Thanks for the feedback. I'll remove WOLFSSL_ABI and we can always add it back in if we want to lock it down

[douzzer]

I think it's probably a mistake to double down on the blinded-error-code oversight in wc_rng_new(). This is the _ex version so this is an opportunity to fix it, with something like

int wc_rng_new_ex(WC_RNG **rng, byte* nonce, word32 nonceSz, void* heap, int devId) {
    int ret;
    *rng = (WC_RNG*)XMALLOC(sizeof(WC_RNG), heap, DYNAMIC_TYPE_RNG);
    [...]
    return ret;
}

Also error shouldn't be used here because it collides with a glibc function.

[bigbrett]

@douzzer addressed API changes in latest commit, lmk what you think

[douzzer]

I agree with @JacobBarthelmeh that we don't need to be boxing ourselves in on this. For one thing, a minor and useful refactor is possible here to allow nonce to be passed in as a const byte *. If we make it WOLFSSL_ABI we can't do that.

I just did an automated survey of the existing WOLFSSL_ABI functions in wolfCrypt and there's only two _ex() functions in the set, wc_ecc_make_key_ex() and wc_ecc_init_ex(). You can be sure there was some specific reason(s) a customer needed those stabilized.

Btw the total number of WOLFSSL_ABI prototypes in wolfCrypt is just 45, of 1120 WOLFSSL_APIs. In the native TLS layer we currently have 52, of 1711 WOLFSSL_APIs. They're rare birds!

[bigbrett]

Jenkins retest this please