Hello Alex,
What model of STM32H7 are you running on?
Kind Regards,
Daniele - wolfSSL Support
You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by danielinux
Pages 1
Hello Alex,
What model of STM32H7 are you running on?
Kind Regards,
Daniele - wolfSSL Support
Hi Arto,
Thanks for reporting these!
- The F4 problem has been fixed now in https://github.com/wolfSSL/wolfBoot/pull/434
- The G0 warnings have been silenced with an explicit cast when retrieving the address of the flags in https://github.com/wolfSSL/wolfBoot/pull/435
We are in the process of releasing a new version (2.1.0) which will contain these fix.
- Regarding the H7 issues they might be indeed small differences in the configuration between the two models. There is a .gdbinit that automatically loads both wolfboot + the test application so you can debug across staging. Please let us know if we can assist further, and adapt the port to support your model. I'd suggest we continue the conversation through our support ticketing system. Feel free to send an email to support at wolfssl.com with as many details you can share about UART3 initialization failure.
Kind Regards,
--
Daniele - wolfSSL
This should be automatically included in your build (arch.mk around line 107):
CFLAGS+=-DSTM32L4A6xx -DUSE_HAL_DRIVER -Isrc -Ihal
This code has been tested with STM32L4A6, but you can change that to match your model
I'm wondering if the include paths are correct and match your current directory structure.
Wolfboot will be looking for that file (and other stm32l4xx_hal*.h) in one of the following:
$(STM32CUBE)/Drivers/STM32L4xx_HAL_Driver/Inc/
$(STM32CUBE)/Drivers/BSP/STM32L4xx_Nucleo_144/
$(STM32CUBE)/Drivers/CMSIS/Device/ST/STM32L4xx/Include/
$(STM32CUBE)/Drivers/CMSIS/Include/
Hi akuraparthy,
The L4 is our only STM32 port that requires drivers from ST. Please download the STM32L4xx_HAL driver from STM and point the STM32CUBE variable in your config to the path, i.e.:
STM32CUBE=/path/to/stm32-cube/in/your/system
Hope this helps.
Thanks,
--
Daniele - wolfSSL
SamR21 has an even less complicated flash driver than STM32L0 and fits below 10KB
(Ed25519/sha384):
[SIZE]
text data bss dec hex filename
9736 0 56 9792 2640 wolfboot.elf
(lms 1-10-8 + sha256)
[SIZE]
text data bss dec hex filename
8564 0 40 8604 219c wolfboot.elf
Thanks,
--
Daniele @wolfSSL Support
> FYI what I am actually trying to do is checking if I can implement a secure bootloader with wolfssl.
We already have that! Check out wolfBoot:
https://github.com/wolfSSL/wolfBoot
It's fully featured and highly portable, you can see we already support some M0's like the STM32L073, the Atmel/Microchip SAM-R21 and Cypress PSOC6.
For your reference about the code size, wolfBoot ECC256+SHA256 on STM32L0 is ~ 18KB in size including crypto, down to ~16KB without assembly optimizations, ~14KB if using ED25519 and SHA384, and even a little smaller if using LMS (post quantum crypto algorithms).
Thanks,
--
Daniele @wolfSSL Support
Hello Nikos,
Happy to hear that everything worked.
WOLFSSL_SMALL_STACK indeed keeps your stack usage low, but requires heap. Anyway I see you have fixed the runtime memory and it looks OK.
Regarding the footprint:
- If you are only using ECC verify, you could disable other functionality and compile them out of the ECC module with the following:
# define NO_ECC_SIGN
# define NO_ECC_DHE
# define NO_ECC_EXPORT
# define NO_ECC_KEY_EXPORT
- there is a trade-off if you are enabling WOLFSSL_SP_ARM_THUMB_ASM ECC will be faster but also larger in size. If you can afford to lose some performance you could use the same implementation in C, which is smaller (and slower). To do so, remove WOLFSSL_SP_ARM_THUMB_ASM and link the file "sp_c32.c" instead of "sp_armthumb.c". The footprint should be now significantly reduced (although taking more time to verify the signature).
Thanks,
--
Daniele @wolfSSL Support
Hello Nikos,
First of all, I think you should use the function wc_ecc_verify_hash_ex() https://www.wolfssl.com/documentation/m … fy_hash_ex. This would eliminate the need for converting the signature from raw (R,S) format to signature, and also make the code smaller. signature.c and asn.c should not be needed in your build if you stick to the APIs in ecc.h instead.
To create the "mp_int" object to import the R,S components in the format expected by this call, you could do the following:
mp_int mp_r, mp_s;
mp_init(&mp_r);
mp_init(&mp_s);
mp_read_unsigned_bin(&mp_r, r, sizeof(r));
mp_read_unsigned_bin(&mp_s, s, sizeof(s));
Very important: before using your ecc_pubkey structure to import the key, you must initialize it:
eccret = wc_ecc_init(&ecc_pubkey);
Your import call then looks fine as is:
// Import the key buffer to the ecc_key structure format
eccret = wc_ecc_import_unsigned(&ecc_pubkey, pubkeyX, pubkeyY, NULL, ECC_SECP256R1);
Then finally you can call the correct verify function as:
eccret = wc_ecc_verify_hash_ex(&mp_r, &mp_s, hash_data, hash_len, &result, &eccpubkey);
If all goes as expected, eccret should be zero and result should be 1, indicating successful verification.
Another thing I have noticed in your configuration: the SP assembly optimizations don't match your current MCU. Cortex-M0 is ARMv6-M and we do provide thumb instructions optimization for it. I suggest you remove the option WOLFSSL_SP_ARM_CORTEX_M_ASM and use WOLFSSL_SP_ARM_THUMB_ASM instead. Also the correct assembly file for Cortex-M0 is sp_armthumb.c if you are compiling with options "-mcortex-m0 -mthumb" as expected for this MCU. The sp_cortexm.c source file contains assembly optimizations for Cortex-M3 and later (up to newer ARMv8-M).
I would also recommend to add the option WOLFSSL_HAVE_SP_ECC to ensure ecc is using those optimizations.
Furthermore, since you are defining WOLFSSL_NO_MALLOC, I expect that you don't have/don't want to use dynamic allocation. In this case, in combination with SP_MATH, I would also suggest the following:
#define WOLFSSL_SP_NO_MALLOC
#define WOLFSSL_SP_NO_DYN_STACK
I hope this helps. Please let us know if you are still experiencing issues after the suggested fixes.
Thanks,
Daniele @wolfSSL Support
Hi Gareth,
Glad to hear this. We have merged the PR. Thanks again for reporting this issue. I'm now adding more unit tests to intercept similar failures.
Best Regards,
--
Daniele
Hello Gareth,
We have recently modified the NVM_FLASH_WRITEONCE code to add redundancy in the last two sectors of each partition, to mitigate the risk of corrupted/incomplete update flags for MCUs requiring this option.
This was introduced in https://github.com/wolfSSL/wolfBoot/pull/276
The problem you are reporting seems indeed a bug introduced in the above PR. The non-selected block address should be rather
(uint32_t)(base - ((1 + (!sel)) * WOLFBOOT_SECTOR_SIZE)) & (~(NVM_CACHE_SIZE - 1);
>
I have submitted a fix here:
https://github.com/wolfSSL/wolfBoot/pull/287 and I'm planning to integrate more tests to avoid such errors in the future.
Please let me know if this fixes the issue for you.
Thanks,
--
Daniele, wolfSSL
Hello bmidgley, thanks for posting this question.
Indeed, the file src\ed25519_pub_key.c is generated once by the keygen.py script. The script depends on the package wolfcrypt-py, that can be obtained using the python package manager:
pip3 install wolfcrypt
or installed from its sources available here:
https://github.com/wolfSSL/wolfcrypt-py/
Regards,
d.
Pages 1
wolfSSL - Embedded SSL Library → Posts by danielinux
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.007 seconds (70% PHP - 30% DB) with 4 queries