Update wolfHSM pointer, fix minor issues

[padelsbach]

• Move wolfHSM submodule like to latest
• Use host-appropriate SP math
• Remove use of deleted whServerCryptoContext.devId in hal/sim.c
• Remove duplicate definition of SP_WORD_SIZE in include/user_settings.h

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #729

Scan targets checked: wolfboot-bugs, wolfboot-src
Findings: 1

Low (1)

Crypto context devId changed from INVALID_DEVID to zero

File: hal/sim.c:173
Function: (file-scope initialization)
Category: HAL implementation flaws

The whServerCryptoContext crypto initialization was changed from explicitly setting .devId = INVALID_DEVID to zero-initialization ({0}). In wolfSSL, INVALID_DEVID is typically defined as -2, so devId will now be 0 instead of -2. A devId of 0 is a valid device identifier, which could cause the HSM server's crypto operations to be routed to an unintended crypto device rather than signaling "no device". This may be intentional if the updated wolfHSM submodule (also changed in this PR) now handles devId initialization internally, but if not, it could alter crypto operation routing in the simulator.

/* Before */
whServerCryptoContext crypto[1] = {{
    .devId = INVALID_DEVID,
}};

/* After */
whServerCryptoContext crypto[1] = {0};

Recommendation: Verify that the updated wolfHSM library (commit 18c46af) initializes devId to INVALID_DEVID internally during server setup, or that a devId of 0 is now the intended sentinel value. If neither is the case, restore the explicit .devId = INVALID_DEVID initialization to ensure crypto operations are not misrouted.

---

This review was generated automatically by Fenrir. Findings are non-blocking.

[padelsbach]

Crypto context devId changed from INVALID_DEVID to zero

This field is no longer present in wolfHSM/wolfhsm/wh_server.h

[danielinux]

Why did you have to change the MlDsa verify API used here?

[danielinux]

Just wondering if there is a reason for this, because it seems to be increasing the size of ML-DSA build by 82B. If it's needed it's not an issue and we can update the footprint limit

[padelsbach]

wolfHSM switched to the new api to pass the FIPS tests and, iiuc, the HSM is used to sign the image and that causes the wolfboot verify to fail -- this is all in the sunny day test.

I'll look into other solutions to fall back to the old API. I had attempted something here, but it's not a complete solution: wolfSSL/wolfHSM#320

Let me know if you have any ideas