[dormancygrace]

Add a separate OpenSSL SHA-224/SHA-256 patch using the existing streaming, padding, context-copy and digest handling. A C906 scalar compression adapter handles software work; direct SG2002 DMA is selected for full compression chunks starting at 4096 B. No cryptodev/ENGINE integration is used, and FIPS is unchanged.

The scalar adapter shares the reviewed generator with our Go/kernel implementation but uses the GNU C ABI. Same-layout native controls measured a compression improvement; full tiny EVP operations are not claimed to improve. Raw scalar trials and source/binary identities are committed in firmware/crypto/experimental/openssl-sha256/. Historical threshold-selection timings are explicitly distinguished from final integration checks.

The final restricted-ISA stack passes 864 native SHA streaming/copy cases with DMA on/off plus upstream SHA vectors. Host ASan/UBSan fault tests cover first/later submission failures and continuation without double hashing; negative controls validate failure visibility. Real HTTPS downloads use production Go file hashing, so those downloads are not presented as OpenSSL SHA speed measurements. The SHA-256 context remains 112 B and hardware requests do not allocate cipher output scratch.

Stacked on #507. SHA-1, DES and TDES offload proposals are excluded from this chain.

The session minimum remains 4096 B; after a successful first request, 512–4032 B tails reuse the open descriptor, with a 4096 B per-request cap. Native verification covers every 64-byte driver length from 512 to 4096 B. Five alternating-order complete-compression trials show −26.7% / −36.1% / −49.2% CPU time for 4096+512 / +1024 / +2048 B, and −21.9% for 8192+512 B. EVP setup and full-library layout effects are excluded from this measurement. Fast CI now applies the full pinned patch stack with zero fuzz and executes the actual SHA wrapper/scalar assembly on QEMU C906: 3440 cases plus four negative controls. Host sanitizer continuation coverage is 3072 cases plus two negative controls. Both review threads are fixed and verified.

[github-actions]

Build outputs

Compared with the build of main at 6c78048; codex/openssl-sg2002 is at a6c9d4c, so outputs changed since then are listed too.

4 changed, 1 added, 0 removed of 595 outputs.

	directory	files
changed	server	server/NanoKVM-Server
changed	tools	tools/openssl/usr/lib/libcrypto.so.3 tools/openssl/usr/lib/ossl-modules/legacy.so tools/openssl/usr/share/nanokvm/openssl/source.json
added	tools	tools/openssl/usr/share/licenses/nanokvm-openssl/C906-BSD-3-Clause.txt
Hashes: outputs-sha256 artifact of this run.

[dormancygrace]

The chaining and fallback logic is right: state is committed only after completed chunks, in/num advance correctly, and the BE state conversion matches. The fallback tests use a software mock of the device, so the hardware byte order and behaviour still need the pending device run, as the description says.

One README note: streams made of many updates under 4096 bytes never reach the threshold, because OpenSSL passes whole blocks straight through. That suits the cost model, but benchmarks should use large updates.

[dormancygrace]

The new scalar SHA-256 is ABI-correct.

• s0–s5 are saved in a 112-byte frame, and the 64-byte schedule is wiped.
• The K table is right.
• All 53 distinct .word values reassemble from th.srriw/th.revw with GNU as.
• The fallback tests pass on the host.

Taking the Go C906 core here makes sense: it beats upstream for SHA-256 (22.4 vs 19.8 MiB/CPU-s). Remaining points below. The CI point from my last review is still open; I added a concrete harness to that thread.

[dormancygrace]

Re-reviewed at b4e7e7e. Two of my four threads are addressed (resolved below); two stay open.

• The README sentence about the "same-layout control replacing three dispatch bytes with the upstream C path" measuring 10–13% better compression throughput is ambiguous. Please say which side was faster: the C906 adapter or the upstream C path.
• The small-size slowdown mentioned in the README (1–128 B slower than the base library) also appears with every new path off in #509 and #512. See the #509 review.

[dormancygrace]

Reviewed 9c3b2ffb. Both remaining threads are fixed and verified: full zero-fuzz patch application and actual C906 assembly/wrapper tests are now in fast CI; DMA sessions handle >=512 B tails while preserving the 4 KiB initial minimum and per-request maximum. The same-binary native transport/compression comparison verifies all 57 driver sizes and demonstrates the continuation gain. This does not claim new whole-EVP timing.

Local checks pass: 3440 QEMU C906 arithmetic/ABI/continuation cases, four negative controls, 3072 host sanitizer fallback cases and two negative controls, plus the original generator check. All fast final-head CI checks pass; no remaining blocking findings in the reviewed changes.

[dormancygrace]

Reviewed the final head 06f3d607432822a2a5159d8c0b3ab1b3411f106d, including the main/parent integration after the fixes in 9c3b2ffb. Both previously outstanding threads remain fixed and verified.

The initial DMA minimum stays 4 KiB; successful sessions continue with tails of at least 512 B, with a 4 KiB request cap and state committed only for completed chunks. Local sanitizer tests pass 3072 SHA-224/256 continuation/fault cases. The pinned-source CI executes the actual scalar assembly and wrapper under QEMU C906: 2096 scalar cases, 1344 wrapper/fault cases and four negative controls.

The committed physical-device compression/transport measurements retain their stated scope. Additional actual EVP SHA-224/256 tests on the final OpenSSL candidate pass all 28 independent known answers across 4096–10000 B with DMA on and off. The SHA patch is byte-identical to that candidate. No new correctness issue found.

All 19 final-head CI checks pass, including the firmware build.