Issues with benchmarks on stm32f4discovery from commit 8582f47bba034524c87d8e1630553d799783a61d #310
Assignees
Comments
|
I'll look into it. As for the compiler: we're using the GNU toolchain supplied by ARM, which right now is based on GCC 13.2. https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads |
|
OK, so because we're currently switching to the Nucleo-L4R5ZI board, I didn't properly test the new stack measurement on the old boards. The linkerscripts aren't right for that. VERY quick fix is the following patch: diff --git a/ldscripts/stm32f4discovery.ld b/ldscripts/stm32f4discovery.ld
index a3fb9f1..fb18aec 100644
--- a/ldscripts/stm32f4discovery.ld
+++ b/ldscripts/stm32f4discovery.ld
@@ -58,6 +58,7 @@ SECTIONS
*(COMMON)
. = ALIGN(4);
_ebss = .;
+ end = .;
} >ram
.ram2 : {
*(.ram2*)
@@ -69,6 +70,5 @@ SECTIONS
} >ccm
/DISCARD/ : { *(.eh_frame) }
. = ALIGN(4);
- end = .;
}
PROVIDE(_stack = ORIGIN(ram) + LENGTH(ram));For some reason, the error doesn't pop up on my MacOS machine, which should be an entirely different issue in itself... But apply the one above, it should work. I'll fix this in a separate test for all the other platforms... |
|
With the patch it works fine! |
|
just to add info: dilithium5 still not working even with the patch... |
mmoeller23
added a commit
to mmoeller23/pqm4
that referenced
this issue
Dec 1, 2023
Add slightly modified reference implementations to haetae2, Add slightly modified reference implementations to haetae2, haetae3 and haetae5 with lower stack memory footprint than the original reference implementation. This enables the test vector comparison for all schemes. CAVEAT: This commit modifies the following PQM4 core files * ldscripts/stm32f4discovery.ld * ldscripts/stm32f4discovery_fullram.ld * mk/stm32f4discovery.mk The two load scripts are modified as recommended in [issue 310](mupq#310 (comment)). The make file is modified to use full ram for the implementations m4f and ref of scheme haetae5, as they would run out of memory otherwise, similar to dilithium5. The stack memory footprint was reduced by: * Storing A1 using uint16 instead of int32, halving its footprint * Grouping some vectors inside `crypto_sign_signature()`, whose periods of liveliness do not overlap, into unions. The modification is light enough to easily verify consistency with the reference implementation.
mmoeller23
added a commit
to mmoeller23/pqm4
that referenced
this issue
Dec 1, 2023
Add slightly modified reference implementations to haetae2, haetae3 and haetae5, labeled as `ref`, with lower stack memory footprint than the original reference implementation. This enables running testvectors.py for all schemes. CAVEAT: This commit modifies the following PQM4 core files * ldscripts/stm32f4discovery.ld * ldscripts/stm32f4discovery_fullram.ld * mk/stm32f4discovery.mk The two load scripts are modified as recommended in [issue 310](mupq#310 (comment)). The make file is modified to use full ram for the implementations m4f and ref of scheme haetae5, as they would run out of memory otherwise, similar to dilithium5. The stack memory footprint was reduced by: * Storing A1 using uint16 instead of int32, halving its footprint * Grouping some vectors inside `crypto_sign_signature()`, whose periods of liveliness do not overlap, into unions. The modification is light enough to easily verify consistency with the reference implementation.
Merged
mmoeller23
added a commit
to mmoeller23/mupq
that referenced
this issue
Dec 1, 2023
This commit implements the post-quantum signature scheme HAETAE from https://eprint.iacr.org/2023/624 https://kpqc.cryptolab.co.kr/haetae Only `config.h` differs between versions, hence most of the files for haetae3 and haetae5 are symlinks. Tested on stm32f4discovery, haetae5 runs with the full RAM linker script and the patch from [issue 310 of PQM4](mupq/pqm4#310 (comment)).
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Starting from commit 8582f47 benchmarks doesn't work for me anymore on stm32f4discovery.
for example if I run:
./benchmarks.py -p stm32f4discovery kyber512
the script last forever... indeed the board output only the start pattern "==========================" and no more characters.
It seems that the new measurement HAL API is not working.
before commit 8582f47 all seems to work fine for me.
I am using compiler arm-none-eabi-gcc (15:10.3-2021.07-4) 10.3.1 20210621 (release) in Ubuntu 22.04.2 LTS
Which compiler are you using?
The text was updated successfully, but these errors were encountered: