aarch64: crypto-extension asm for the AES-XTS streaming path - #11386
aarch64: crypto-extension asm for the AES-XTS streaming path#11386kaleb-himes wants to merge 1 commit into
Conversation
wolfSSL-Fenrir-bot
left a comment
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #11386
Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src
Findings: 2
2 finding(s) posted as inline comments (see file-level comments below)
This review was generated automatically by Fenrir. Reported findings require changes before merge.
| byte plain[WC_AES_BLOCK_SIZE * 10]; | ||
| byte ref[sizeof(plain)]; | ||
| byte buf[sizeof(plain)]; | ||
| static const word32 chunk[] = { WC_AES_BLOCK_SIZE * 4, |
There was a problem hiding this comment.
New streaming chunk sizes never exercise the 4-block loop exit or multi-block ciphertext stealing · Missing edge-case coverage on a function the PR also changed
The chunks are 4, 2, 3 and 1 blocks, and the final chunk is block-aligned. The 4-block loop in the new AES_XTS_{en,de}crypt_update_AARCH64 is therefore only entered with an exact multiple of 4 blocks, so its hand-off into the 2-block/1-block/partial tails — where the running tweak moves from x11-x16 back to x9/x10 — stays untested, as does stealing after more than one full block.
Fix: Add a chunk of 5-7 blocks and make the final call non-block-aligned so the 4x loop exit and multi-block stealing paths execute.
There was a problem hiding this comment.
Will fix the test routines.
| #ifdef WC_AES_XTS_STREAM_AARCH64 | ||
| /* Same lane the one-shot wc_AesXtsEncrypt() takes. */ | ||
| if (aes->use_aes_hw_crypto) { | ||
| AES_XTS_encrypt_update_AARCH64(in, out, sz, (byte*)aes->key, |
There was a problem hiding this comment.
aarch64 streaming XTS lane enabled for the MASM backend, which lacks the new routines · Logic errors
WC_AES_XTS_STREAM_AARCH64 is gated only on __aarch64__ && WOLFSSL_ARMASM && !WOLFSSL_ARMASM_NO_HW_CRYPTO, but armv8-aes-asm.asm (assembled by armasm64 for MSVC ARM64, where settings.h:429 maps _M_ARM64 to __aarch64__) defines no AES_XTS_encrypt_update_AARCH64/AES_XTS_decrypt_update_AARCH64. Those builds fail to link with WOLFSSL_AESXTS_STREAM.
Fix: Regenerate armv8-aes-asm.asm with the two streaming routines in this PR, or exclude the MASM backend from WC_AES_XTS_STREAM_AARCH64.
There was a problem hiding this comment.
The MASM routines are added in #11370 and https://github.com/wolfSSL/scripts/pull/670. This is simply Fenrir being blind to the other two PR's, once both "J" branches are merged this will resolve, we can hold back the "L" branches till "J's" merge and re-run Fenrir.
2 participants
Description
Add the aarch64 streaming API's for user space
aarch64: AES-XTS streaming assembly and callers
Adds AES_XTS_encrypt_update_AARCH64 / AES_XTS_decrypt_update_AARCH64 as armv8-aes-asm.S and armv8-aes-asm_c.c, plus the aes.c callers and aes.h prototypes. The MASM twin is in https://github.com/wolfSSL/scripts/pull/670, which adds no callers, so this PR is what makes the routines reachable.
test.c gains a streaming case using multi-block chunks, checked against the one-shot result; the existing tests only ever pass one block, leaving the 4x path uncovered.
armv8-aes-asm_c.c also picks up 42 bcc/bcs → b.cc/b.cs at pre-existing sites: upstream's committed copy is stale against upstream's own generator. Same encodings, no behavior change.
Generator: wolfSSL/scripts#. Committed files reproduce byte-for-byte.
Note: the simultaneous-keys streaming test fails until J's key-schedule fix merges. Pre-existing, not from this PR.
Pairs with: https://github.com/wolfSSL/scripts/pull/674
Testing
emulated, baremetal and virtualized.
Checklist