[dormancygrace]

Add a separate OpenSSL SHA-1 compression wrapper using direct SG2002 DMA from 8192 B. OpenSSL retains streaming, padding, context copy, digest length and software continuation; FIPS is unchanged. No cryptodev or ENGINE interface is introduced.

Native threshold selection rejected 4096 B because it was slower than software, and selected 8192 B. The alternative Go-derived scalar implementation also lost, so the small-input path keeps upstream C906/O3 code. Historical raw/median results and original binary identities are retained in firmware/crypto/experimental/openssl-sha1/ and are labelled separately from final integration qualification.

The final restricted-ISA stack passes 864 native SHA streaming/copy cases with DMA enabled/disabled and upstream SHA vectors. Host ASan/UBSan fault/continuation tests cover partial progress and fallback without double hashing. The SHA-1 context remains 96 B. Stacked on #508; this PR contains only the SHA-1 integration.

[dormancygrace]

I found nothing specific to this PR. I checked:

• the wrapper placement in sha_local.h, for both the normal and the small-footprint definitions;
• the BE state conversion;
• that state is committed only after completed chunks;
• the 5-word state.

The CI gap from #508 applies here as well: the OpenSSL hunks are never applied or compiled in CI. The hardware run is still pending.

[github-actions]

Build outputs

Compared with the build of main at 2571baa; codex/openssl-sha256 is at b4e7e7e, so outputs changed since then are listed too.

4 changed, 159 added, 145 removed of 584 outputs.

	directory	files
changed	opensbi	opensbi/build-manifest.json (records the hash of platform/build.sh)
changed	server	server/NanoKVM-Server server/nkos-update
changed	web	web/index.html
added	tools	14 files
added	web	145 files
removed	web	145 files
Hashes: outputs-sha256 artifact of this run.

[dormancygrace]

The code is correct, and the 8 KiB threshold fits the three measured points. My question is whether this patch should ship at all. On the Go side, SRTP HMAC-SHA1 runs in internal/sha1mb and does not use OpenSSL.

[dormancygrace]

Which OpenSSL consumer on the device hashes more than 8 KiB per update with SHA-1? The gain exists only above 8 KiB per call: 1.2× at 8 KiB and 1.65× at 16 KiB. The cost is that the patch wraps upstream's block function in sha_local.h, which has to be requalified at every OpenSSL bump.

The 8 KiB crossover comes mostly from the transport's fixed cost per call. By the rows in the README, that is about 66 µs, against about 26 µs per 4 KiB request. Unless there is a named consumer, I would hold this patch until the #507 per-call cost is reduced, then re-measure. The crossover should drop to about 4 KiB (my estimate).

[dormancygrace]

Re-reviewed at 9443d91. The new native-medians.json answers my data request, but it shows a regression that needs attribution before this stack ships.

Same trials, base vs candidate-off (patched library, DMA off), SHA-1 digest, MiB/CPU-s:

Size	base	candidate-off	Δ	Δ per op
64 B	12.36	9.74	−21%	+1.33 µs
256 B	29.87	25.96	−13%	+1.24 µs
1 KiB	46.33	43.68	−6%	+1.28 µs
16 KiB	56.14	55.50	−1%	+3.2 µs

The per-operation difference is almost constant. At 64 B the new code does only num >= 128 and then calls the C block function. That comparison cannot cost about 1300 cycles, so this patch is unlikely to be the cause. The same pattern appears elsewhere in the stack:

• #512 DES-CBC encrypt at 64 B: 3.22 → 2.74.
• #506 ChaCha at 64 B: 6.84 → 6.39.
• #508: "1–128 B slower than the base library".

These medians come from the historical candidate builds. The final stack was rerun for correctness but not for timing, so the difference may be a build-flag difference that is already gone. Cheapest first check: a 64 B SHA-1 row with DMA off, on the base and on the final binaries pinned in native-final-validation.json. If the gap persists, bisect with DSOs that add one patch at a time (#504 base, +0001, +0002, +0003, +0004). The sha256 control-c build is the right kind of control. Then either fix it or state the small-digest cost in the README.

The consumer question in my other thread is still open.

[dormancygrace]

Owner decision (2026-10-27): no OpenSSL consumer on the device hashes SHA-1 at 8 KiB or more per call, so the SHA-1 offload is dropped. This PR is the base of #511, so it stays open until #511 is restacked (see #511); then please close it.

[dormancygrace]

Closing this SHA-1 offload PR because it has no intended device consumer. AES #511 now targets SHA-256 #508 directly, and GHASH #527 follows the cleaned AES branch; neither contains these SHA-1 commits or the SHA-1 CI step. Both final heads pass all 15 checks. Closed without merging.