Async crypto v2 by bigbrett · Pull Request #15 · bigbrett/wolfHSM

bigbrett · 2026-04-13T20:28:25Z

No description provided.

Copilot

Pull request overview

This PR updates the wolfHSM SHA2 client/server “wire format” and APIs to support multi-block variable-length SHA requests and introduces async Request/Response split operations (including DMA variants), with accompanying test expansion and POSIX example buffer sizing updates.

Changes:

Redesign SHA256/SHA224 and SHA512/SHA384 request messages to carry variable-length trailing input (inSz) instead of fixed inBlock/lastBlockLen.
Add async SHA{256,224,384,512} Request/Response client APIs (plus DMA async variants) and update server handlers + message translation accordingly.
Expand crypto tests to cover large inputs, capacity boundaries, and new async flows; increase POSIX example comm/transport buffer sizing.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
`wolfhsm/wh_message_crypto.h`	Updates SHA2 request/DMA message structs for variable-length trailing input; adds inline-capacity macros and static asserts.
`wolfhsm/wh_client_crypto.h`	Adds public async SHA2 Request/Response API declarations and DMA async prototypes.
`wolfhsm/wh_client.h`	Adds per-operation DMA async context storage to survive Request/Response for POST cleanup.
`src/wh_message_crypto.c`	Updates request/response translation to match new SHA2 message layouts and new DMA request types.
`src/wh_server_crypto.c`	Updates SHA2 handlers to validate `inSz`, process variable-length input, and rework DMA SHA2 handling with inline state.
`src/wh_client_crypto.c`	Implements async SHA2 APIs (non-DMA + DMA), refactors blocking wrappers to use them.
`test/wh_test_crypto.c`	Adds reference hashes and extensive large-input + async (DMA and non-DMA) SHA2 tests.
`test/wh_test_check_struct_padding.c`	Updates padding checks for renamed DMA request structs.
`examples/posix/wh_posix_server/wolfhsm_cfg.h`	Sets comm data length to 8 KiB to match client.
`examples/posix/wh_posix_client/wolfhsm_cfg.h`	Sets comm data length to 8 KiB.
`examples/posix/wh_posix_cfg.h`	Adjusts SHM request/response buffer sizes to carry the larger comm packets.

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

Copilot

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated 8 comments.

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

Copilot · 2026-04-16T16:37:35Z

+ * Contract: at most one outstanding async SHA256 request per wc_Sha256
+ * instance. Caller MUST call wh_Client_Sha256UpdateResponse if and only if
+ * *requestSent is true before issuing another Request on the same sha.


The async SHA256 contract here says only one outstanding request per wc_Sha256 instance, but wh_Client_SendRequest stores last_req_kind/last_req_id on the whClientContext, so issuing any other async request on the same ctx before calling the matching Response will break response validation. The contract should be stated in terms of whClientContext (or explicitly note both constraints).

Suggested change

* Contract: at most one outstanding async SHA256 request per wc_Sha256

* instance. Caller MUST call wh_Client_Sha256UpdateResponse if and only if

* *requestSent is true before issuing another Request on the same sha.

* Contract: at most one outstanding async request may exist per

* whClientContext. If *requestSent is true, caller MUST call

* wh_Client_Sha256UpdateResponse before issuing another async Request on the

* same ctx. The caller must also not issue another Request on the same sha

* until that matching Response has completed.

Copilot · 2026-04-16T16:37:35Z

+    ret = wh_MessageCrypto_TranslateSha256DmaRequest(
+        magic, (const whMessageCrypto_Sha256DmaRequest*)cryptoDataIn, &req);


Potential unaligned 64-bit access: cryptoDataIn points to the algorithm-specific struct immediately after whMessageCrypto_GenericRequestHeader (12 bytes) which starts at whCommHeader+8. This makes cryptoDataIn typically 4-bytes mod 8, but whMessageCrypto_Sha256DmaRequest contains uint64_t DMA fields that wh_MessageCrypto_TranslateSha256DmaRequest/TranslateDmaBuffer read via WH_T64. On strict-alignment targets this can fault. Consider memcpy'ing the fixed-size request header into an aligned local before translation, or changing DMA translation to use memcpy-based loads for uint64 fields instead of direct struct access.

Copilot · 2026-04-16T16:37:36Z

+    ret = wh_MessageCrypto_TranslateSha512DmaRequest(
+        magic, (const whMessageCrypto_Sha512DmaRequest*)cryptoDataIn, &req);


Potential unaligned 64-bit access: same issue as the SHA256 DMA handler. cryptoDataIn is offset by 12 bytes (GenericRequestHeader), so casting it to whMessageCrypto_Sha512DmaRequest and translating uint64 DMA fields via WH_T64 can fault on strict-alignment architectures. Prefer memcpy into an aligned local struct first, or update DMA translation helpers to use memcpy-based loads for uint64 fields.

Copilot · 2026-04-16T16:37:36Z

    ret = wh_MessageCrypto_TranslateDmaBuffer(magic, &src->input, &dest->input);
    if (ret != 0) {
        return ret;
    }


These DMA request translations ultimately read uint64 DMA buffer fields from src via WH_T64 (in wh_MessageCrypto_TranslateDmaBuffer). Because the on-wire layout places DMA request structs immediately after a 12-byte GenericRequestHeader, src is typically not 8-byte aligned. On strict-alignment targets, direct uint64 loads from an unaligned src are undefined and may fault. Consider changing DMA buffer translation to use memcpy-based loads/stores for uint64 fields (and/or require/pad the generic header to 16 bytes).

Copilot · 2026-04-16T16:37:36Z

+- **No message format changes**: the same wire protocol is used; only the
+  client-side calling pattern changes.


The design principle "No message format changes" conflicts with the rest of this document, which specifies a new SHA wire layout (variable-length trailing input with inSz, and new DMA request structs). Consider rewording this bullet to reflect that the async API may introduce new message formats, or scope the claim to algorithms where the wire protocol is unchanged.

Suggested change

- **No message format changes**: the same wire protocol is used; only the

client-side calling pattern changes.

- **Preserve existing wire formats where possible**: for operations whose

request/response layout is already suitable, the async API only changes the

client-side calling pattern. Some algorithms may still require new message

layouts to carry async-specific inputs or DMA metadata.

Copilot · 2026-04-16T16:37:36Z

+ * Contract: at most one outstanding async SHA224 request per wc_Sha224
+ * instance. Caller MUST call wh_Client_Sha224UpdateResponse if and only if
+ * *requestSent is true before issuing another Request on the same sha.


Same as SHA256: the contract should reflect that only one async request can be in flight per whClientContext because response matching uses ctx->last_req_kind/last_req_id. As written, this suggests multiple hashes could overlap on the same ctx as long as they are different wc_Sha224 instances, which would be incorrect.

Suggested change

* Contract: at most one outstanding async SHA224 request per wc_Sha224

* instance. Caller MUST call wh_Client_Sha224UpdateResponse if and only if

* *requestSent is true before issuing another Request on the same sha.

* Contract: at most one outstanding async request per whClientContext.

* Caller MUST call wh_Client_Sha224UpdateResponse if and only if

* *requestSent is true before issuing another async Request on the same ctx,

* regardless of which wc_Sha224 instance is used.

Copilot · 2026-04-16T16:37:37Z

+ * Contract: at most one outstanding async SHA384 request per wc_Sha384
+ * instance. Caller MUST call wh_Client_Sha384UpdateResponse if and only if
+ * *requestSent is true before issuing another Request on the same sha.


Same as SHA256: the contract should reflect that only one async request can be in flight per whClientContext because response matching uses ctx->last_req_kind/last_req_id. As written, this suggests multiple hashes could overlap on the same ctx as long as they are different wc_Sha384 instances, which would be incorrect.

Suggested change

* Contract: at most one outstanding async SHA384 request per wc_Sha384

* instance. Caller MUST call wh_Client_Sha384UpdateResponse if and only if

* *requestSent is true before issuing another Request on the same sha.

* Contract: at most one outstanding async request may be in flight per

* whClientContext. Caller MUST call wh_Client_Sha384UpdateResponse if and

* only if *requestSent is true before issuing any other async Request on

* the same ctx, even when using a different wc_Sha384 instance.

Copilot · 2026-04-16T16:37:37Z

+ * Contract: at most one outstanding async SHA512 request per wc_Sha512
+ * instance. Caller MUST call wh_Client_Sha512UpdateResponse if and only if
+ * *requestSent is true before issuing another Request on the same sha.


Same as SHA256: the contract should reflect that only one async request can be in flight per whClientContext because response matching uses ctx->last_req_kind/last_req_id. As written, this suggests multiple hashes could overlap on the same ctx as long as they are different wc_Sha512 instances, which would be incorrect.

Suggested change

* Contract: at most one outstanding async SHA512 request per wc_Sha512

* instance. Caller MUST call wh_Client_Sha512UpdateResponse if and only if

* *requestSent is true before issuing another Request on the same sha.

* Contract: at most one outstanding async request may be in flight per

* whClientContext. If *requestSent is true, the caller MUST call

* wh_Client_Sha512UpdateResponse before issuing any other async request on

* the same ctx, including a request using a different wc_Sha512 instance.

…in comm layer

bigbrett requested a review from Copilot April 14, 2026 18:34

Copilot started reviewing on behalf of bigbrett April 14, 2026 18:34 View session

Copilot AI reviewed Apr 14, 2026

View reviewed changes

Comment thread src/wh_client_crypto.c Outdated

Comment thread examples/posix/wh_posix_cfg.h

Comment thread wolfhsm/wh_message_crypto.h

Comment thread wolfhsm/wh_message_crypto.h

Comment thread src/wh_client_crypto.c

bigbrett force-pushed the async-crypto-v2 branch from f12c904 to b19155f Compare April 15, 2026 22:32

bigbrett requested a review from Copilot April 16, 2026 16:30

Copilot started reviewing on behalf of bigbrett April 16, 2026 16:30 View session

Copilot AI reviewed Apr 16, 2026

View reviewed changes

bigbrett force-pushed the async-crypto-v2 branch from 67f2927 to 6c7e032 Compare April 16, 2026 17:19

bigbrett added 2 commits April 16, 2026 11:29

Add native async API for SHAx

9a82567

fix gcov option for gcov bug

7ef52c5

bigbrett force-pushed the async-crypto-v2 branch from 6c7e032 to 7ef52c5 Compare April 16, 2026 17:32

bigbrett added 7 commits April 16, 2026 12:28

add defensive buf len check

2244bc0

review: fixes to enforce only one pending request/response at a time …

3f727a4

…in comm layer

Merge branch 'main' into async-crypto-v2

854fa4c

update docs

f055450

review: clear async state, check for hash type in client, set in server

609c532

review: relax client SHA512 hash type matching constraints

c0e965f

review: fix typo

97b9cd6

bigbrett merged commit 655e1c9 into main Jul 8, 2026
90 of 91 checks passed

Navigation Menu

Async crypto v2 - #15

Async crypto v2#15
bigbrett merged 9 commits into
mainfrom
async-crypto-v2

bigbrett commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Copilot AI Apr 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

- * Contract: at most one outstanding async SHA256 request per wc_Sha256
- * instance. Caller MUST call wh_Client_Sha256UpdateResponse if and only if
- * *requestSent is true before issuing another Request on the same sha.
+ * Contract: at most one outstanding async request may exist per
+ * whClientContext. If *requestSent is true, caller MUST call
+ * wh_Client_Sha256UpdateResponse before issuing another async Request on the
+ * same ctx. The caller must also not issue another Request on the same sha
+ * until that matching Response has completed.

		ret = wh_MessageCrypto_TranslateSha256DmaRequest(
		magic, (const whMessageCrypto_Sha256DmaRequest*)cryptoDataIn, &req);

		ret = wh_MessageCrypto_TranslateSha512DmaRequest(
		magic, (const whMessageCrypto_Sha512DmaRequest*)cryptoDataIn, &req);

		- No message format changes: the same wire protocol is used; only the
		client-side calling pattern changes.

-- **No message format changes**: the same wire protocol is used; only the
-  client-side calling pattern changes.
+- **Preserve existing wire formats where possible**: for operations whose
+  request/response layout is already suitable, the async API only changes the
+  client-side calling pattern.  Some algorithms may still require new message
+  layouts to carry async-specific inputs or DMA metadata.

- * Contract: at most one outstanding async SHA224 request per wc_Sha224
- * instance. Caller MUST call wh_Client_Sha224UpdateResponse if and only if
- * *requestSent is true before issuing another Request on the same sha.
+ * Contract: at most one outstanding async request per whClientContext.
+ * Caller MUST call wh_Client_Sha224UpdateResponse if and only if
+ * *requestSent is true before issuing another async Request on the same ctx,
+ * regardless of which wc_Sha224 instance is used.

- * Contract: at most one outstanding async SHA384 request per wc_Sha384
- * instance. Caller MUST call wh_Client_Sha384UpdateResponse if and only if
- * *requestSent is true before issuing another Request on the same sha.
+ * Contract: at most one outstanding async request may be in flight per
+ * whClientContext. Caller MUST call wh_Client_Sha384UpdateResponse if and
+ * only if *requestSent is true before issuing any other async Request on
+ * the same ctx, even when using a different wc_Sha384 instance.

Conversation

bigbrett commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants