Repository navigation
crypto: offload OpenSSL Triple DES ECB and CBC to SG2002 - #513
dormancygrace wants to merge 18 commits into
Conversation
dormancygrace
left a comment
There was a problem hiding this comment.
I found nothing specific to this PR.
- The 2-key copy (16 bytes, with
ctx->keylen16) and the 3-key copy (24 bytes) are right. - The 2-key and 3-key variants share
ossl_cipher_hw_tdes_cbcand_ecbcorrectly. - The kernel accepts both 16- and 24-byte keys.
The verify.c CI note from #512 applies here as well. Minor: the DES and TDES dispatch snippets are identical, and a shared include would remove the duplication.
dormancygrace
left a comment
There was a problem hiding this comment.
The TDES wiring mirrors DES and the native data supports offload. The same shipping question as for #512 applies: 3DES-CBC is reachable through the default provider, but realistic users on this device (old PKCS#12/PBES1 key files) process a few hundred bytes.
| PROV_TDES_CTX *tctx = (PROV_TDES_CTX *)ctx; | ||
| + | ||
| +#if defined(__riscv) && __riscv_xlen == 64 && !defined(FIPS_MODULE) | ||
| + if (inl >= 1024) { |
There was a problem hiding this comment.
At 1024 B, EDE3-CBC is already 2.3× faster with DMA (3.249 → 7.578 MiB/CPU-s), so 1024 is where the measurement started, not where DMA breaks even. From the two README points, the fit is about 105 µs per call plus about 23 ns/B, which puts break-even near 400 B (my estimate). Please measure 128/256/512 B (ECB and CBC, both directions) and set the minimum from that.
The #if + if (len >= 1024) + pointer-advance block is now repeated four times across 0006/0007. A small shared helper in sg2002.h that returns the processed prefix, with the minimum checked only inside ossl_sg2002_cipher, would remove that duplication. openssl-c906/README.md line 81 still says the minimum needs native validation.
Build outputsCompared with the build of main at 2571baa; codex/openssl-des is at 6ac974a, so outputs changed since then are listed too. 4 changed, 159 added, 145 removed of 584 outputs.
|
dormancygrace
left a comment
There was a problem hiding this comment.
Re-reviewed at f7f020f. The wiring is unchanged and still correct.
- Continuation floor: the same point as #512. Both calls pass
1024, 1024. TDES software runs at about 3.4 MiB/CPU-s, so a held-fd RUN (about 22.5 µs) covers only about 80 bytes. Please use a measured continuation value, or 512. - My threshold thread stays open: the data still has only 1 KiB and 16 KiB points, so 1024 is where measurement started. Rows at 256 and 512 B would show where DMA actually breaks even.
|
Owner decision (2026-10-27): Triple DES has no consumer on the device, so this offload is dropped. Closing. |
Use direct SG2002 DMA for two-key and three-key Triple DES ECB/CBC prefixes from 1024 B, retaining upstream C906/O3 software below the threshold or after hardware failure. OpenSSL owns buffering, padding, IV continuation and key/context handling. No cryptodev or ENGINE integration is added.
Both initial and continuation minima remain 1024 B. The context grows from 584 to 608 B for the retained key; no output buffer is retained per context. Historical native selection measured EDE3-CBC encryption at 7.578 vs 3.249 MiB/CPU-s for 1 KiB and 32.17 vs 3.484 for 16 KiB. Those original binary identities and trial results are retained and are not presented as timings of later builds.
The final restricted-ISA stack after the AES interface/lookup changes passes native DMA on/off: 1944 block, 864 SHA, 288 CTR, 408 AEAD, 2160 GCM and 20,736 AES tail/IV cases, plus upstream DES/AES/SHA/ChaCha vectors. The legacy provider loads successfully. Host ASan/UBSan continuation/failure tests and negative controls pass.
native-final-validation.jsonrecords the final libcrypto/legacy provider identities and all patch digests.Stacked on #512. DES and other algorithms have their own patches/PRs.