Repository navigation
Conversation
Provide 256 KiB for the shared Zephyr test application so the full ML-DSA-87 eager/lazy polynomial unit suite fits. Retain the board-specific Nucleo stack override. Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Advance partial-lane pointers to the next eight-byte lane and use bounded byte accesses whenever a next-lane pointer is unaligned. Retain the aligned gather/scatter paths and regenerate production assembly from dev sources. Align both helpers with merged mlkem-native PR #1766 at d2f26d6e22a6cb38ebf5a3c73f0912cbe0066912; extraction repair originated in this PR. Generic regression coverage follows separately. Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Extend the x1-reference differential test with the eight equal/mixed buffer offsets and thirteen extraction boundary cases from merged mlkem-native PR #1766. Use independent MLD_ALLOC buffers, output guards, and a serial-only configuration guard. Route comparison and guard failures through cleanup to release every buffer under custom allocation. Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Run full unit suites on the existing Cortex-M3/M4/M7/M33/M55 matrix, retaining both portable and native AN547 configurations. Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Signed-off-by: Brendan Moran <brendan.moran@arm.com>
Contributor
CBMC Results (ML-DSA-44, REDUCE-RAM-X4)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-44, REDUCE-RAM)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-44)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-65, REDUCE-RAM)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-65, REDUCE-RAM-X4)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-65)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-87, REDUCE-RAM-X4)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-87, REDUCE-RAM)
Full Results (445 configurations)
|
Contributor
CBMC Results (ML-DSA-87)
Full Results (445 configurations)
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add reduced-RAM x4 matrix batching
Why
Reduced-RAM x1 did not meet the desired speed, while retaining the full matrix for x4 requires substantially more RAM. Hanno suggested a middle course: process four matrix rows at a time so we can reuse the existing SHAKE128x4 implementation without keeping the full matrix in memory. No code change alone improves x1's latency; selecting full-RAM x4 has the larger RAM cost. A two-row batch would leave half the x4 lanes unused or need another backend.
An earlier ML-DSA-87 N657 campaign illustrates the tradeoff with the hand-optimized Keccak backend:
In that campaign, reduced-RAM x4 used 31.2% fewer mean signing cycles than x1 and 73.3% less sampled caller-inclusive signing stack than full-RAM x4. It also used 7,524 B more sampled stack and 5,840 B more code than x1, and was slower than full-RAM x4. These are historical whole-configuration measurements, not measurements of this PR head. The stack figures are samples, not proven peaks.
What changes
MLD_CONFIG_REDUCE_RAM_X4for ML-DSA-44, 65, and 87. It requiresMLD_CONFIG_REDUCE_RAMand rejectsMLD_CONFIG_SERIAL_FIPS202_ONLY. The existing default and x1 configuration remain available.scripts/tests, and generic and Zephyr CI coverage. The Zephyr transition test verifies that the requested x4 binary is built and executed after a scalar build in the same cache.The work is divided seven commits: configuration and guards; batching; native Keccak selection; tests and runner; CBMC; generic CI; Zephyr CI.
The configuration header copies are generated from the repository's canonical configuration source.
scripts/autogenregenerated them without a diff in the prior validation run.Base and scope
This branch is based directly on the revised #1470 branch (
origin/armv81m-x4-byte-accessat40a8f1137). This change does not replace full-RAM x4 or alter the default configuration. The static Bring-Your-Own-FIPS202 example remains serial-only and cannot select this x4 mode; the non-serial custom-FIPS202 path was exercised.Validation so far
The batching preserves FIPS 204's
ExpandAseed order (rho || column || row) and the existing NTT and Montgomery reduction boundaries. The new batch decisions depend on public row and column indices. Functional, vector, focused proof and source review results support that reasoning; compiled constant-time evidence is still pending.