SHA-3: fix wrong digest on refused vector claim, v7 gates, build fixes

[kaleb-himes]

Description

SHA-3: vector-register brackets, arm32 and PowerPC/RISC-V builds, FIPS v7 service gates

The vector-register claim around the Keccak-f[1600] permutation was taken after the
sponge had already been modified, so a refused claim left a corrupted context and a
retry returned success with the wrong digest. This fixes the brackets, pins the
implementation at build time for certifiable builds, and closes two build
configurations that did not link or selected the wrong block. Rebased on master after
the aarch64 claim work landed in #11423, so none of that is duplicated here.

Problem on master	This PR
Sha3Final pads before claiming; a refused claim corrupts the context	Claim before the pad absorb
arm32 NEON block runs without holding the registers, no guard exists	Claim keyed on the NEON block; NO_NEON builds claim none
A certifiable build can switch to the C Keccak block at run time	Compiled out for v7 and fips-ready only
KMAC/cSHAKE have no CAST or service gate, yet v7 auto-enables them	Dropped in settings.h; configure refuses an explicit ask
wc_Sha3_SetFlags accepts the non-approved Keccak-256 pad under v7	Refuse with FIPS_NOT_ALLOWED_E, context-independent
AVX2 chosen ahead of BMI2; a duplicate macro leaves one branch dead	BMI2 first, it needs no claim; one live AVX2 branch
--enable-fips=v7 with riscv64 or ppc64 asm does not link at all	The v7 source list builds the AES asm, as v5 and v6 do
WC_SHA3_NO_ASM takes the PowerPC asm arm with prototypes suppressed	Undefine the PowerPC asm macros too, so the C block wins

Two of those are AES build plumbing rather than SHA-3: the BUILD_FIPS_V7_PLUS
block in src/include.am never listed the RISC-V or ppc64 AES assembly, though the
non-FIPS block and both the v5 and v6 FIPS blocks do, so --enable-fips=v7 --enable-riscv-asm failed on undefined references to the AES entry points. FIPS v7
on those two targets was unbuildable, which is also how it was found: the SHA-3 lane
work needed a FIPS v7 RISC-V build to test on and there wasn't one before now!

Scope: WC_C_DYNAMIC_FALLBACK

This PR targets --enable-fips=v7 (including --enable-linuxkm). It does not extend
the run-time C fallback anywhere, and it does not remove it anywhere it works today.

Build	C-block fallback sites
non-FIPS	4, unchanged
FIPS v6	4, unchanged**
FIPS v7 dev / dev-no-post	4, unchanged
FIPS v7 and fips-ready	0, compiled out

** v6 module has live graceful C runtime fallback but there are presently no plans to use the v6 module in kernel space. Will need to resolve those through an UPDT submission if the v6 module ever gets used as a KM.

It is compiled out only for the certifiable builds, where one build carrying two
implementations of a single algorithm would need a CAST for each under FIPS 140-3 IG
10.3.A GeneralNote1, and the SHAKE CAST only ever exercises the lane that was live
when it ran.

aarch64 with WC_C_DYNAMIC_FALLBACK has never compiled, on master either (6
compile errors on both this branch and its base). This PR deliberately does not fix
that. WC_C_DYNAMIC_FALLBACK is not supported in a certifiable build, so a
never-built fallback path on aarch64 is not needed for the --enable-fips=v7 --enable-linuxkm target and repairing it is out of scope here.

The fallback arm requires USE_INTEL_SPEEDUP, so it is not compiled on Arm at all:
arm32 has zero fallback sites in every flavor, FIPS or not. That condition is what
keeps the new arm32 claim block from pulling the fallback arm into a target that has
no sha3_block to assign (5 compile errors without it). No fallbacks removed or added
by design.

Testing

14 configurations. Every measurement carries a control, so a number that cannot move
is reported as a failure rather than a pass.

Check	Result
FIPS v7, fips-ready, and v7 with --enable-all, full make check	PASS
Refused-claim retry returns the correct digest	PASS
Run-time C block switches (v7 vs dev control)	0 vs 4
arm32 claim sites (NO_NEON vs NEON control)	0 vs 4
aarch64 + WC_C_DYNAMIC_FALLBACK vs base (parity, not a fix)	6 vs 6 errors
arm32 + WC_C_DYNAMIC_FALLBACK vs base (no regression)	0 vs 0 errors
v7 refuses Keccak-256 and explicit KMAC; non-FIPS and dev keep both	PASS
FIPS v7 on real RISC-V hardware (BeagleV PolarFire SoC)	PASS
Thumb-2 block integer-only; WC_SHA3_NO_ASM on ppc64 picks C block	PASS
Generated SHA-3 port assembly reproduces byte-for-byte (11 files)	PASS

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[kaleb-himes]

@wolfSSL-Fenrir-bot review force

Dismiss to re-request

Fenrir is bikeshedding now, only identifying items out of scope of this PR, dismissing automated review.