1

(3 replies, posted in wolfBoot)

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

2

(5 replies, posted in wolfBoot)

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

3

(5 replies, posted in wolfBoot)

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/

4

(5 replies, posted in wolfBoot)

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

9

(3 replies, posted in wolfBoot)

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

10

(3 replies, posted in wolfBoot)

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

11

(1 replies, posted in wolfBoot)

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.