feat: route configurable devId through key init calls

[MarkAtwood]

Summary

wolfProvider currently hardcodes INVALID_DEVID in all key initialization
calls, silently bypassing wolfCrypt's device callback layer. This makes it
impossible to route OpenSSL operations through a wolfHSM server (or any
other wolfCrypt device callback) via the provider interface.

This PR closes that gap for RSA, ECC, and DH:

• Adds int devId to WOLFPROV_CTX, initialized to INVALID_DEVID (no behavior change for existing users)
• Exposes wolfprovider_devid as a settable OSSL_PARAM so callers can configure the device ID at runtime
• Routes devId through RSA (wc_InitRsaKey_ex), ECC (wc_ecc_init_ex), and DH (wc_InitDhKey_ex) key init calls
• Routes devId through the ECX gen-context RNG init (wc_InitRng_ex)

Known gap

ECX key init functions (wc_curve25519_init, wc_ed25519_init, wc_ed448_init) use WP_ECX_INIT function pointers typed as int(*)(void*), which carry no devId parameter. Routing devId through ECX key init requires changing the table shape and all four call sites — that is a larger, separate change. The RNG used during ECX key generation does use devId after this PR.

wc_curve448_init_ex does not exist in wolfCrypt as of wolfSSL 5.x, so curve448 cannot be fixed without a wolfCrypt change.

Behavior for existing users

devId defaults to INVALID_DEVID, so all existing behavior is unchanged unless the caller explicitly sets wolfprovider_devid via OSSL_PROVIDER_set_params.

Test plan

• Existing wolfProvider test suite passes (no regression)
• RSA sign/verify routes through wolfHSM device callback when wolfprovider_devid is set to WH_DEV_ID
• ECC sign/verify routes through wolfHSM device callback when wolfprovider_devid is set
• DH key agreement routes through wolfHSM device callback when wolfprovider_devid is set
• Setting wolfprovider_devid to INVALID_DEVID restores direct wolfCrypt behavior

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Routes a configurable wolfCrypt devId through provider-managed key/RNG initialization to enable device callback routing (e.g., wolfHSM) instead of always using INVALID_DEVID.

Changes:

• Adds devId to WOLFPROV_CTX and sets a default of INVALID_DEVID.
• Exposes wolfprovider_devid via provider settable_params/set_params.
• Passes devId into RSA/ECC/DH key init and ECX keygen RNG init.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/wp_wolfprov.c	Adds provider parameter plumbing and default devId in provider context.
src/wp_rsa_kmgmt.c	Uses provCtx->devId for RSA key init and RSA keygen RNG init.
src/wp_ecx_kmgmt.c	Uses provCtx->devId for ECX keygen RNG init (not ECX key init).
src/wp_ecc_kmgmt.c	Uses provCtx->devId for ECC key init.
src/wp_dh_kmgmt.c	Uses provCtx->devId for DH key init.
include/wolfprovider/internal.h	Adds devId to the provider context struct.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

wolfprovider_devid is being advertised as a gettable provider parameter via wolfssl_param_types, but this PR only adds support for setting it (wolfprov_set_params). This is an API contract mismatch: either implement returning the current value in wolfprov_get_params, or remove it from the gettable table and keep it only in wolfprov_settable_params.

Suggested change

OSSL_PARAM_int("wolfprovider_devid", NULL),

[Copilot]

ctx->devId becomes runtime-mutable via wolfprov_set_params, and is read concurrently in multiple algorithm init paths (RSA/ECC/DH/ECX RNG). In C, an unsynchronized read/write to the same non-atomic object across threads is a data race (undefined behavior). Consider making devId an atomic type (or guarding reads/writes with an existing/new mutex), or documenting/enforcing that wolfprovider_devid must only be set before any concurrent operations begin.

[Copilot]

ctx->devId becomes runtime-mutable via wolfprov_set_params, and is read concurrently in multiple algorithm init paths (RSA/ECC/DH/ECX RNG). In C, an unsynchronized read/write to the same non-atomic object across threads is a data race (undefined behavior). Consider making devId an atomic type (or guarding reads/writes with an existing/new mutex), or documenting/enforcing that wolfprovider_devid must only be set before any concurrent operations begin.

[Copilot]

The parameter name string literal is duplicated in multiple places. To reduce the risk of typos and make future refactors easier, define a single constant/macro (e.g., #define WP_PARAM_DEVID "wolfprovider_devid") and use it consistently across the gettable/settable/set handlers.

[Copilot]

The parameter name string literal is duplicated in multiple places. To reduce the risk of typos and make future refactors easier, define a single constant/macro (e.g., #define WP_PARAM_DEVID "wolfprovider_devid") and use it consistently across the gettable/settable/set handlers.

[Copilot]

The parameter name string literal is duplicated in multiple places. To reduce the risk of typos and make future refactors easier, define a single constant/macro (e.g., #define WP_PARAM_DEVID "wolfprovider_devid") and use it consistently across the gettable/settable/set handlers.