[nebeid]

Issues

N/A

Description of Changes

Add runtime and static detection of the Neoverse-V3 microarchitecture (Graviton5, MIDR part 0xD84) and group it with Neoverse-V1/V2 for selecting AWS-LC's fastest AArch64 implementations.

Why

AWS-LC gates several of its fastest AArch64 code paths on a microarchitecture allowlist (Neoverse-V1/V2, Apple-M). Neoverse-V3 was not on that list, so on Graviton5 the library silently fell through to
slower fallbacks. Measured on a c9g (Neoverse-V3) instance, with every dispatch path trap-verified at the object-code level:

Workload	Before (fallback)	After (V-core path)	Delta
AES-128-GCM, 16 KB	6135 MB/s (4x kernel)	8854 MB/s (8x-EOR3)	+44%
RSA-2048 sign	1227 ops/s (s2n-bignum)	2025 ops/s (generic)	+65%
RSA-2048 verify	49986 ops/s	77819 ops/s	+56%
SHAKE256-x4, 16 KB	Neon-SHA3 keccak2 (413 MB/s)	V-core alt2 (448 MB/s)	+8%

Changes

• arm_arch.h: add ARMV8_NEOVERSE_V3 (bit 1<<18) and ARM_CPU_PART_V3 (0xD84); update the CPU-indicator-bit mask comments (0x7080→0x47080, 0x78fc→0x478fc).
• cpu_aarch64_linux.c: detect the V3 MIDR at runtime; set the V3 bit and the N1-subset bit (matching the existing V1/V2 pattern).
• cpucap.c: static-armcap support via OPENSSL_STATIC_ARMCAP_NEOVERSE_V3 / __ARM_FEATURE_NEOVERSE_V3.
• internal.h: add V3 to the AES-GCM-8x and wide-multiplier gates; add CRYPTO_is_Neoverse_V3(); exclude V3 from CRYPTO_is_Neoverse_N1() (since detection also sets the N1-subset bit, V3 must be excluded here or it would be mis-classified as N1 and mis-route Keccak).
• keccak1600.c: group V3 with V1/V2 at both dispatch sites.
• all_tests.json: update the CPU-indicator armcap masks used by the "dispatch without CPU indicator bits" tests to include the V3 bit.
• CI: add a linux-graviton5-c9g-2xlarge CodeBuild fleet and agraviton5 job in linux_arm_omnibus.yml (mirrors the graviton4 job).

Testing

• Built and ran crypto_test on a Neoverse-V3 (c9g) instance; all tests pass and the FIPS module links cleanly.
• Each dispatch decision (GCM 8x, generic Montgomery, Keccak alt2) was trap-verified on hardware to confirm the intended kernel executes.
• Benchmarks above collected on c9g with warmup + averaged repeated runs.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[github-actions]

🔒 Security Review — View Report

Please review before merging.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.19%. Comparing base (b822cec) to head (b6866c3).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3374      +/-   ##
==========================================
- Coverage   78.40%   78.19%   -0.22%     
==========================================
  Files         695      695              
  Lines      124222   124220       -2     
  Branches    17265    17261       -4     
==========================================
- Hits        97400    97136     -264     
- Misses      25899    26162     +263     
+ Partials      923      922       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hanno-becker]

I am surprised that we see a speedup here. V3 has SHA3 instruction support on all Neon units, and should use the path L450ff (like Apple silicon CPUs)-- or so I thought.

[nebeid]

We investigated and benchmarked V3 on both paths: the SHA3-extension path you're pointing at (L450ff, sha3_keccak2_f1600 run twice) and the V1/V2 grouping (sha3_keccak4_f1600_alt2). Both were trap-verified at the object-code level to confirm the intended kernel actually executed, warmup + 7 reps, SHAKE256-x4 Absorb @ 16 KB:

core	alt2 (V1/V2 path)	keccak2 (SHA3-ext path, L450ff)	delta
V2 (Graviton4)	264.9 MB/s	120.8 MB/s	alt2 +119%
V3 (Graviton5)	447.8 MB/s	413.5 MB/s	alt2 +8.3%

You're right that V3 closes the gap dramatically — this is exactly the effect of the improved SHA3 units you describe: the keccak2 SHA3-extension path jumps 120.8 → 413.5 MB/s (3.4×) from V2 to V3, so it nearly catches alt2. But alt2 still wins on V3 by ~8%, so grouping V3 with V1/V2 is the (narrowly) faster choice here rather than routing it to the Apple-silicon path. The margin is small enough that if a future V-core flips the ordering we'd want to revisit, but on measured Graviton5 the V-grouping is correct.

(Numbers are on stock c9g / r8g; V3 ~3.29 GHz vs V2 ~2.79 GHz.

[nebeid]

On another note, while looking into your point, I also checked the single-buffer (x1) path on V3, since the same "V3 has full-width SHA3" reasoning could apply there too. To rule out measurement drift on a shared instance, I ran both paths interleaved (A/B/A/B per rep, pinned core, prebuilt trap-verified binaries, 40 reps):

x1 kernel	V3 (MB/s)
sha3_keccak_f1600 (scalar lazy-rot, what V3 gets)	914
sha3_keccak_f1600_alt (SHA3-extension)	832

Scalar won 40/40 interleaved reps (+9.9% mean).

The x4 comparison in this thread held up the same way — alt2 won 40/40 reps (+8.4%) over the SHA3-ext path. So V3 stays grouped with N1/V1/V2 at both x1 and x4.

This doesn't contradict the wider SHA3 units — the scalar lazy-rotation kernel is just very good on V3's scalar/barrel-shift path — so I've kept the "SHA3 on 1/4 Neon units" comment scoped to V1/V2.

[hanno-becker]

Pre-existing: I think it is confusing to set the NEOVERSE_N1 capability on a CPU that is not an N1. ISTM that one should set at most a one CPU-specific capability (none if the CPU is not detected). If NEOVERSE_N1 is used as an indicator of certain architectural capabilities that all Neoverse cores offer, that deserves a separate helper.

[nebeid]

We resorted to that solution to be able to test N1-specific code paths on a Vx machine in FIPS ACVP testing as detailed in #2815. ACVP testing relies on setting the OPENSSL_armcap environment variable to test the various code paths included in the module.

[hanno-becker]

Thank you @nebeid!

Rationale: we can think of the N1 capabilities as a subset of those of V1 and V2, so enabling its bit is semantically valid

I can see the motivation, thank you. However, is overloading the CPU capability for N1 the right solution? Now, ARMV8_NEOVERSE_N1 stands both for a specific CPU and for an unspecified set of architecture capabilities. It is also not the case that we are building hierarchical capabilities -- e.g. V2 does not set the V1 capability.

Have you considered introducing a separate capability capturing which aspects of N1 you care about here?

[manastasova]

My understanding is that the V2 and V1 code paths overlap, thus there is (currently) no need for setting the additional flag — and the same applies to V3.
On the other hand, I am also wondering about the value of setting the V1/V2 flag on V3, in case a new code path is introduced for V3 — a V3 machine wouldn't otherwise be able to reach and test the V1/V2 code paths. It could be done later when/if needed, but it also could be missed, as it is not obvious that it is needed for the tests. Perhaps we could add a note.

[nebeid]

Thank you for your review, Hanno.

[nebeid]

We investigated and benchmarked V3 on both paths: the SHA3-extension path you're pointing at (L450ff, sha3_keccak2_f1600 run twice) and the V1/V2 grouping (sha3_keccak4_f1600_alt2). Both were trap-verified at the object-code level to confirm the intended kernel actually executed, warmup + 7 reps, SHAKE256-x4 Absorb @ 16 KB:

core	alt2 (V1/V2 path)	keccak2 (SHA3-ext path, L450ff)	delta
V2 (Graviton4)	264.9 MB/s	120.8 MB/s	alt2 +119%
V3 (Graviton5)	447.8 MB/s	413.5 MB/s	alt2 +8.3%

You're right that V3 closes the gap dramatically — this is exactly the effect of the improved SHA3 units you describe: the keccak2 SHA3-extension path jumps 120.8 → 413.5 MB/s (3.4×) from V2 to V3, so it nearly catches alt2. But alt2 still wins on V3 by ~8%, so grouping V3 with V1/V2 is the (narrowly) faster choice here rather than routing it to the Apple-silicon path. The margin is small enough that if a future V-core flips the ordering we'd want to revisit, but on measured Graviton5 the V-grouping is correct.

(Numbers are on stock c9g / r8g; V3 ~3.29 GHz vs V2 ~2.79 GHz.

[nebeid]

We resorted to that solution to be able to test N1-specific code paths on a Vx machine in FIPS ACVP testing as detailed in #2815. ACVP testing relies on setting the OPENSSL_armcap environment variable to test the various code paths included in the module.

[hanno-becker]

@nebeid Thank you for digging into this. I missed that V3 has faster Barrel shifter than Apple M cores.

It is interesting to note that if scalar ~= Neon, than 2x scalar + 1x Neon (hybrid) ~= 2x Neon (non-hybrid), with the LHS's apparently winning slightly in each case.

Note that leave quite a bit of performance on the table here: In 2x scalar + 1x Neon, the Neon unit is busy only half of the time because the scalar is the bottleneck. An optimal hybrid would use 1x scalar + 1x Neon, but that would be a 3x-batch, which we have no APIs for. The amortized cost of 1x scalar + 1x Neon would be 1/3 (because it's a x3 batch), whereas the amortized cost of 2x scalar + 1x Neon is 1/2 because it's a x4 batch (one unit being the Scalar/Neon cost in each case).

We may want evaluate whether it's worth allowing an x3-native version for Keccak in mlx-native.