I'm trying to use wolfBoot on QEMU virt machine model for RISC-V.
When updating firmware from emulated flash, I found that update partition was not measured correctly.

Checking compiled binary, I noticed that the type_field and version_field values are ignored.
Each variable is used in libwolfboot.c#wolfBoot_get_image_type() and libwolfboot.c#wolfBoot_get_blob_version().

I also find same variable in functions related delta update, but I did not try delta update and don't know whether this has same issue.

Details

By default, gcc optimization seems to set to -Os. This options generate the assembly below.

0000000080000de2 <wolfBoot_get_blob_version>:
    80000de2:   4118                    lw      a4,0(a0)
    80000de4:   1101                    addi    sp,sp,-32
    80000de6:   464c57b7                lui     a5,0x464c5
    80000dea:   ec06                    sd      ra,24(sp)
    80000dec:   e402                    sd      zero,8(sp)
    80000dee:   f5778793                addi    a5,a5,-169 # 464c4f57 <STACK_SIZE+0x464c4b57>
    80000df2:   00f71763                bne     a4,a5,80000e00 <wolfBoot_get_blob_version+0x1e>
    80000df6:   0030                    addi    a2,sp,8
    80000df8:   4585                    li      a1,1
    80000dfa:   0521                    addi    a0,a0,8
    80000dfc:   f73ff0ef                jal     ra,80000d6e <wolfBoot_find_header>
    80000e00:   60e2                    ld      ra,24(sp)
    80000e02:   4501                    li      a0,0
    80000e04:   6105                    addi    sp,sp,32
    80000e06:   8082                    ret

The function expects to return the value of the version_field, but 0 is stored directly in a0 through any flow, and 0 is always returned. I investigated using the debugger and found that this was the cause of the problem.

I fixed this problem by simply adding volatile to version_field or type_field.
This is example of version_field.

uint32_t wolfBoot_get_blob_version(uint8_t *blob)
{
    uint32_t * volatile version_field = NULL;
    uint32_t *magic = NULL;

    magic = (uint32_t *)blob;
    if (*magic != WOLFBOOT_MAGIC)
        return 0;
    if (wolfBoot_find_header(blob + IMAGE_HEADER_OFFSET, HDR_VERSION,
            (void *)&version_field) == 0)
        return 0;
    if (version_field)
        return im2n(*version_field);
    return 0;
}

Assembly changed to this.

0000000080000de2 <wolfBoot_get_blob_version>:
    80000de2:   4118                    lw      a4,0(a0)
    80000de4:   1101                    addi    sp,sp,-32
    80000de6:   464c57b7                lui     a5,0x464c5
    80000dea:   ec06                    sd      ra,24(sp)
    80000dec:   e402                    sd      zero,8(sp)
    80000dee:   f5778793                addi    a5,a5,-169 # 464c4f57 <STACK_SIZE+0x464c4b57>
    80000df2:   00f70663                beq     a4,a5,80000dfe <wolfBoot_get_blob_version+0x1c>
    80000df6:   4501                    li      a0,0
    80000df8:   60e2                    ld      ra,24(sp)
    80000dfa:   6105                    addi    sp,sp,32
    80000dfc:   8082                    ret
    80000dfe:   0030                    addi    a2,sp,8
    80000e00:   4585                    li      a1,1
    80000e02:   0521                    addi    a0,a0,8
    80000e04:   f6bff0ef                jal     ra,80000d6e <wolfBoot_find_header>
    80000e08:   d57d                    beqz    a0,80000df6 <wolfBoot_get_blob_version+0x14>
    80000e0a:   67a2                    ld      a5,8(sp)
    80000e0c:   d7ed                    beqz    a5,80000df6 <wolfBoot_get_blob_version+0x14>
    80000e0e:   67a2                    ld      a5,8(sp)
    80000e10:   4388                    lw      a0,0(a5)
    80000e12:   b7dd                    j       80000df8 <wolfBoot_get_blob_version+0x16>

It correctly returned value of version_field.

I can't determine if this problem is specific to my environment, so I will share it with you.

Compiler toolchain: RISC-V GNU Toolchain Tag:2022.06.10
Options in arch.mk is below. Some sources are modified by me for riscv64.

## RISCV
ifeq ($(ARCH),RISCV)
  ifeq ($(TARGET), riscv_virt)
    ## For Qemu virt emulation
    CROSS_COMPILE:=riscv64-unknown-elf-
    CFLAGS+=-fno-builtin-printf -DUSE_M_TIME -g -march=rv64imac -mabi=lp64 -mcmodel=medany -nostartfiles -DARCH_RISCV -DRISCV_QEMU_VIRT
    LDFLAGS+=-march=rv64imac -mabi=lp64 -mcmodel=medany
    MATH_OBJS += ./lib/wolfssl/wolfcrypt/src/sp_c32.o
    CFLAGS +=-ffunction-sections -fdata-sections
    LDFLAGS+=-Wl,--gc-sections
    OBJS+=src/boot_riscv64.o src/vector_riscv64.o
  else

Thanks.

Version

Latest

Description

Can anyone please point out some use cases for having wolfssl.efi build?
Also, is there any guide for that?

Thanks

Hi

I'm currently trying to integrate wolfBoot on a STM32H743 microcontroller. On this chip the flash is ECC protected. Therefore you cannot write to the same flash word (256 bit) more than once, because the ECC value is calculated and stored the first time you write to it. wolfBoot does so when triggering an update: Once to set the partition magic and once to set the partition state. This then results in a fault when reading because the ECC value is invalid.

What is the proper solution to solve this problem? If there is none, are you planning to add support for this use case?

Thanks!

This is a very interesting project. Do you have a cortex M4 integration on your roadmap?

Good morning,

I am using WolfBoot 2.0.2 on STM32U585.

I am using dual swap capability and in normal condition all works like a charm.

My Flash partition is:

0x08000000 --> Wolfboot
0x08010000 --> Boot Image
0x08110000 --> Update image

The only (maybe) problem seems to occurs under this condition.

1. load a good image candidate at attress 0x08110000.
2. reboot the MCU

Then WolfBoot will execute

void RAMFUNCTION hal_flash_dualbank_swap(void)
{
    uint32_t cur_opts;
    hal_flash_unlock();
    hal_flash_opt_unlock();
    cur_opts = (FLASH_OPTR & FLASH_OPTR_SWAP_BANK) >> 20;
    if (cur_opts)
        FLASH_OPTR &= (~FLASH_OPTR_SWAP_BANK);
    else
        FLASH_OPTR |= FLASH_OPTR_SWAP_BANK;
    hal_flash_opt_lock();
    hal_flash_lock();
    stm32u5_reboot();
}

setting FLASH_OPTR_SWAP_BANK bit and reboot again the MCU.
I notice that if a power failure occurs during the execution of fork_bootloader()

void hal_init(void)
{
#if defined(DUALBANK_SWAP) && defined(__WOLFBOOT)
    if ((FLASH_OPTR & (FLASH_OPTR_SWAP_BANK | FLASH_OPTR_DBANK)) == FLASH_OPTR_DBANK)
        fork_bootloader();

then the MCU is locked forever because FLASH_OPTR_SWAP_BANK was previously set to 1 and at location 0x08100000 there is wrong code or no code at all due to powerfailure.

My solution was to comment this line of code

//    if ((FLASH_OPTR & (FLASH_OPTR_SWAP_BANK | FLASH_OPTR_DBANK)) == FLASH_OPTR_DBANK)
//        fork_bootloader();

and to preload the WolfBoot binary at
0x08000000 --> Wolfboot
0x08100000 --> Wolfboot

In this way I solved the problem.

Am I missing something? Maybe I am doing something wrong.

Thank you

Is it possible to transfer tools to the language of PYTHON ? That would be very convenient.

Hello,

I'm trying to run wolfboot on an STM32F401RE along with a user application generated with cubeMX.
here is my repo: https://github.com/kaizoku-oh/wolfboot-iar-example
Basically I have an IAR workspace that contains 2 projects bootloader(wolfboot) and application (blinky + printf).
I also added 3 batch scripts to remove and generate keys as well as sign the application binary.

I can compile both projects (bootloader and application) with no problem.
But after flashing the binaries nothing happens, (if the app starts the led should be blinking and should be able to see UART messages).
I don't know if I'm missing something or if there is a way to debug the bootloader to see why it didn't jump to the application.

Here is the configuration I used and the steps I followed for both bootloader and application:

Bootloader

IAR preprocessor defines:

__WOLFBOOT
PLATFORM_stm32f4
ARCH_ARM
WOLFSSL_USER_SETTINGS
DEBUG_CONSOLE_ASSERT_DISABLE=1
WOLFBOOT_SIGN_ECC256
WOLFBOOT_HASH_SHA256
WOLFSSL_SP_ASM
WOLFSSL_SP_ARM_CORTEX_M_ASM
ARCH_FLASH_OFFSET=0x08000000
WOLFBOOT_FIXED_PARTITIONS

target.h: (common file used by bootloader and application)

#ifndef H_TARGETS_TARGET_
#define H_TARGETS_TARGET_

#define WOLFBOOT_SECTOR_SIZE                 0x20000
#define WOLFBOOT_PARTITION_BOOT_ADDRESS      0x20000
#define WOLFBOOT_PARTITION_SIZE              0x20000 
#define WOLFBOOT_PARTITION_UPDATE_ADDRESS    0x40000
#define WOLFBOOT_PARTITION_SWAP_ADDRESS      0x60000

#endif /* !H_TARGETS_TARGET_ */

1. generate keys: generate_key.bat

PS D:\wolfboot-iar-example\tools> .\generate_key.bat

2. build the bootloader project

Application

IAR preprocessor defines:

__WOLFBOOT
USE_HAL_DRIVER
STM32F401xE
WOLFBOOT_FIXED_PARTITIONS
PLATFORM_stm32f4
ARCH_ARM
WOLFSSL_USER_SETTINGS
DEBUG_CONSOLE_ASSERT_DISABLE=1
WOLFBOOT_SIGN_ECC256
WOLFBOOT_HASH_SHA256
WOLFSSL_SP_ASM
WOLFSSL_SP_ARM_CORTEX_M_ASM

IAR ICF linker file: (as you can see I modified the flash start address from 0x08000000 to 0x08020100

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x08020100;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__    = 0x08020100;
define symbol __ICFEDIT_region_ROM_end__      = 0x0803FFFF;
define symbol __ICFEDIT_region_RAM_start__    = 0x20000000;
define symbol __ICFEDIT_region_RAM_end__      = 0x20017FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x200;
/**** End of ICF editor section. ###ICF###*/


define memory mem with size = 4G;
define region ROM_region      = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region      = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region   { readonly };
place in RAM_region   { readwrite,
                        block CSTACK, block HEAP };

system_stm32f4xx.c:

#define USER_VECT_TAB_ADDRESS

#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00020100U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */

1. build the application project

2. sign app binary: sign_app.bat

PS D:\wolfboot-iar-example\tools> .\sign_app.bat 1

Flashing

I followed the same steps mentioned in the docs here

Is there a plan to develop USART driver support for STM32U5? I didn't see any USART interfaces in (https://github.com/wolfSSL/wolfBoot/tree/master/hal)/stm32u5.c

I didn't see any STM32U5 support in (https://github.com/wolfSSL/wolfBoot)/[hal](https://github.com/wolfSSL/wolfBoot/tree/master/hal)/uart/

The IAR example project for stm32f4 found under IDE/IAR is not able to compile.
After generating the keypair using the generate_key.bat script I wasn't able to compile the project.
I'm using IAR 8.50.9 on Windows 10 x64.
I feel like I'm missing something?

Curious if you are going to be implementing a pre-configured PIC32 HAL target in the future?

I would adopt this boot-loader for our devices if this was the case.
Thanks,
Gordon

Device tree blob (dtb) on Aarch64 does not use partition to check for hash or signature. See e.g.:

• wolfBoot/src/update_ram.c

  Line 130 in 4706d2f

  if (wolfBoot_open_image(&os_image, PART_DTS_BOOT) >= 0) {

• wolfBoot/src/image.c

  Line 602 in 4706d2f

  if (part == PART_DTS_BOOT || part == PART_DTS_UPDATE) {

Is this on purpose? :)

Hi!
I have issues when trying to build the bootloader firmware via cmake.

I tried to build the project using the following command:

mkdir build && cd build && cmake -DWOLFBOOT_TARGET=stm32h7 -DWOLFBOOT_PARTITION_BOOT_ADDRESS=0x8020000 -DWOLFBOOT_SECTOR_SIZE=0x20000 -DWOLFBOOT_PARTITION_SIZE=0xD0000 -DWOLFBOOT_PARTITION_UPDATE_ADDRESS=0x80F0000 -DWOLFBOOT_PARTITION_SWAP_ADDRESS=0x81C0000 .. && make

It's the example command available in the README.md file without the -DTEST_APPS flag to avoid building the baremetal test application, as I only want the bootloader.bin. With this, wolfboot.bin and wolfboot.elf are not being built (but they are in the Makefile version: cp config/examples/stm32h7.config .config && make wolfboot.bin). How can I avoid building the test apps when I only want the wolfboot bootloader firmware using cmake?

The logs are:

-- The C compiler identification is GNU 13.2.1
-- The CXX compiler identification is GNU 13.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building for stm32h7
-- Cross-compiling using GNU arm-none-eabi toolchain
-- Signing image using ECC256
-- Using SHA256 hash
-- Using C Keytools
-- Using fast math
-- Configuring done (0.5s)
-- Generating done (0.0s)
-- Build files have been written to: /<REDACTED>/wolfBoot/build
[...]
[  5%] Building C object CMakeFiles/wolfboothal.dir/hal/stm32h7.c.o
[ 10%] Linking C static library libwolfboothal.a
[ 10%] Built target wolfboothal
[ 15%] Building signing tool
[ 21%] Building keygen tool
[ 21%] Built target keytools
[ 26%] Generating keystore.c and signing private key
<REDACTED>
[ 31%] Building C object CMakeFiles/public_key.dir/keystore.c.o
[ 36%] Linking C static library libpublic_key.a
[ 42%] Built target public_key
[ 47%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/integer.c.o
[ 52%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/tfm.c.o
[ 57%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/ecc.c.o
[ 63%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/memory.c.o
[ 68%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/wc_port.c.o
[ 73%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/wolfmath.c.o
[ 78%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/hash.c.o
[ 84%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/sha256.c.o
[ 89%] Linking C static library libwolfcrypt.a
[ 89%] Built target wolfcrypt
[ 94%] Building C object CMakeFiles/wolfboot.dir/src/libwolfboot.c.o
[100%] Linking C static library libwolfboot.a
[100%] Built target wolfboot

I also have issues when I try to reconfigure the project. Rerunning the cmake command above generates the following logs:

✦ ❯ cmake -DWOLFBOOT_TARGET=stm32h7 -DWOLFBOOT_PARTITION_BOOT_ADDRESS=0x8020000 -DWOLFBOOT_SECTOR_SIZE=0x20000 -DWOLFBOOT_PARTITION_SIZE=0xD0000 -DWOLFBOOT_PARTITION_UPDATE_ADDRESS=0x80F0000 -DWOLFBOOT_PARTITION_SWAP_ADDRESS=0x81C0000 ..
-- Building for stm32h7
-- Cross-compiling using GNU arm-none-eabi toolchain
-- Signing image using ECC256
-- Using SHA256 hash
-- Using C Keytools
-- Using fast math
-- Configuring done (0.0s)
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/bin/arm-none-eabi-gcc
CMAKE_CXX_COMPILER= /usr/bin/arm-none-eabi-g++

-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/usr/bin/arm-none-eabi-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/<REDACTED>/wolfBoot/build/CMakeFiles/CMakeScratch/TryCompile-e4htJH'
    
    Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_3a1e1/fast
    /usr/bin/make  -f CMakeFiles/cmTC_3a1e1.dir/build.make CMakeFiles/cmTC_3a1e1.dir/build
    make[1]: Entering directory '/<REDACTED>/wolfBoot/build/CMakeFiles/CMakeScratch/TryCompile-e4htJH'
    Building C object CMakeFiles/cmTC_3a1e1.dir/testCCompiler.c.o
    /usr/bin/arm-none-eabi-gcc    -o CMakeFiles/cmTC_3a1e1.dir/testCCompiler.c.o -c /<REDACTED>/wolfBoot/build/CMakeFiles/CMakeScratch/TryCompile-e4htJH/testCCompiler.c
    Linking C executable cmTC_3a1e1
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_3a1e1.dir/link.txt --verbose=1
    /usr/bin/arm-none-eabi-gcc CMakeFiles/cmTC_3a1e1.dir/testCCompiler.c.o -o cmTC_3a1e1
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-exit.o): in function `exit':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/stdlib/exit.c:65:(.text.exit+0x28): undefined reference to `_exit'
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-closer.o): in function `_close_r':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/reent/closer.c:47:(.text._close_r+0x18): undefined reference to `_close'
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-lseekr.o): in function `_lseek_r':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/reent/lseekr.c:49:(.text._lseek_r+0x24): undefined reference to `_lseek'
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-readr.o): in function `_read_r':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/reent/readr.c:49:(.text._read_r+0x24): undefined reference to `_read'
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-writer.o): in function `_write_r':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/reent/writer.c:49:(.text._write_r+0x24): undefined reference to `_write'
    /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/lib/libc.a(libc_a-sbrkr.o): in function `_sbrk_r':
    /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/newlib/../../../newlib-4.3.0.20230120/newlib/libc/reent/sbrkr.c:51:(.text._sbrk_r+0x18): undefined reference to `_sbrk'
    collect2: error: ld returned 1 exit status
    make[1]: *** [CMakeFiles/cmTC_3a1e1.dir/build.make:99: cmTC_3a1e1] Error 1
    make[1]: Leaving directory '/<REDACTED>/wolfBoot/build/CMakeFiles/CMakeScratch/TryCompile-e4htJH'
    make: *** [Makefile:127: cmTC_3a1e1/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:43 (project)


-- Configuring incomplete, errors occurred!

I guess cmake doesn't like the multiarch build between the static libs (arm-none-eabi) and the keytools.

Thanks,

Hi, I encountered a potential problem while building wolfBoot

This occurs if someone uses make config to walk-through setting up the platform, architecture and partition settings.

Problem: Make config doesn’t ask for WOLFBOOT_DTS_BOOT_ADDRESS and WOLFBOOT_DTS_UPDATE_ADDRESS. Problem appears only if there is MMU define in effect for the target architecture.

Compiler:

src/image.c: In function ‘wolfBoot_open_image’:
src/image.c:604:44: error: expected expression before ‘:’ token
  604 |                                            : (void*)WOLFBOOT_DTS_UPDATE_ADDRESS;
      |                                            ^
make: *** [Makefile:166: src/image.o] Error 1

This isn’t a problem if user uses config/examples as a template to wolfBoot root as .config

Is there a way to use firmware encryption in internal flash rather than external?

key_import does not match RSA file import

and RSA2048 KeySize not 320.its 294

and then another thing,,,,uhmmm. maybe not a question。

because i do not use the special section to set this keystore.

In the document: Targets.md in line 34
Did you mean:

the swap space must be as big as 128KB

instead of:

the swap space must be as big as 64KB

@Tweakie
Found a potential buffer overflow in wolfBoot.
If row_offset in ext_flash_decrypt_read is different than 0, ext_flash_decrypt_read will write len + ENCRYPT_BLOCK_SIZE - row_offset bytes to the buffer given to ext_flash_decrypt_read. If this buffer has the same size than len, ext_flash_decrypt_read will overwrite the data after this buffer.
I encountered this issue during an encrypted delta upgrade.

Note that ext_flash_decrypt_read will always write at least ENCRYPT_BLOCK_SIZE bytes to the given buffer. If the buffer is smaller than ENCRYPT_BLOCK_SIZE, a buffer overflow will occur.

Created this issue based on #252

WolfBoot crashes to alignment fault on unaligned access during sha3 calculation on the Raspberry Pi 3b hardware. Running on QEMU Raspberry Pi 3b mode is ok and no alignment exception occurs. Unaligned access occurs in the Wolfcrypt sha3 implementation (sha3.c) at https://github.com/wolfSSL/wolfssl/blob/0d995527aa76a2333b558fcf259145c2646b4c72/wolfcrypt/src/sha3.c#L557

Apparently "AArch64 does permit unaligned data accesses to Normal (not Device) memory with the regular load/store instructions." However in the early stages of the boot all memory is treated as device memory (MMU is not enabled), and this is probably how it should be for the bootloader since the actual payload (like Linux kernel) may expect pristine and clean state to start with. Potentally related background on the armv8 behaviour: https://armv8-ref.codingbelief.com/en/chapter_d4/d42_8_the_effects_of_disabling_a_stage_of_address_translation.html

Following gadget will workaround this issue by using xmemcpy instead of 64-bit load/store when access is not aligned on 8-byte boundary:

--- a/lib/wolfssl/wolfcrypt/src/sha3.c
+++ b/lib/wolfssl/wolfcrypt/src/sha3.c
@@ -554,7 +554,14 @@ static word64 Load64BitBigEndian(const byte* a)
 
     return n;
 #else
-    return *(word64*)a;
+    word64 ret;
+
+    if ((unsigned long) a % 8) {
+        XMEMCPY(&ret, a, sizeof(word64));
+        return ret;
+    }
+
+    return *(const word64*)a;

With that workaround there is a performance hit but no crash and Wolfboot can be used to boot up Linux kernel successfully.

Both Raspberry Pi 3b hardware and Qemu crash in gicv2_init_secure() function https://github.com/wolfSSL/wolfBoot/blob/master/src/boot_aarch64.c#L74. You can get both Qemu and Raspberry Pi to boot linux kernel if it is conditionally (or commenting) out (and an unrelated alignment fix is made) . Seems like gicv2_init_secure() function was originally added for QNX kernel boot on ZynQ 6b6d561

I'm currently trying to use wolfboot as stage 3 bootloader for RP2040.
I made HAL and Linker script.
When i try to compile WolfBoot, i have the following error:
....

[build] Output image(s) successfully created.
[build] lib/wolfssl/wolfcrypt/src/sp_armthumb.c: In function 'sp_256_mul_8':
[build] lib/wolfssl/wolfcrypt/src/sp_armthumb.c:96958:1: error: r7 cannot be used in 'asm' here
[build] 96958 | }
[build] | ^
[build] make[3]: *** [lib/wolfssl/wolfcrypt/src/sp_armthumb.o] Error 1
[build] make[2]: *** [CMakeFiles/wolfboot] Error 2
[build] make[1]: *** [CMakeFiles/wolfboot.dir/all] Error 2

This come from the configuration CORTEX_M0?=1
(because rp2040 has dual-core Cortex-M0+ )
If i remove it (Cortex-M0=0) , it compile correctly.

Am i doing something wrong ?

Does it support power down protection for image integrity and upgrade process continuously in the case of power down suddently.

When compiling for i.MX RT10xx I get the following error

core/devices/MIMXRT1042/MIMXRT1042.h:32067:65: error: operator '*' has no right operand
32067 | #define LPUART1                                  ((LPUART_Type *)LPUART1_BASE)

I've not hit this problem before, as we've been running with a slightly custom wolfBoot version internally.

A solution would be to compare the actual base address as an integer instead of a pointer, i.e. using LPUART1_BASE instead of LPUART1.

Hello, I´m trying to use WolfBoot in one of my projects. I use Keil uVision 5.27 and the target is STM32F429ZIT6 microcontroller (Nucleo-144 STM32F429 Board). I´m facing the following issue:

Inside boot_arm.c file the function:

void RAMFUNCTION do_boot(const uint32_t *app_offset)
{
    mpu_off();
#ifndef NO_VTOR
    /* Disable interrupts */
    asm volatile("cpsid i");
    /* Update IV */
    VTOR = ((uint32_t)app_offset);
#endif

    /* Get stack pointer, entry point */
    app_end_stack = (*((uint32_t *)(app_offset)));
    app_entry = (void *)(*((uint32_t *)(app_offset + 1)));

    /* Update stack pointer */
    asm volatile("msr msp, %0" ::"r"(app_end_stack));
#ifndef NO_VTOR
    asm volatile("cpsie i");
#endif
    /* Unconditionally jump to app_entry */
    asm volatile("mov pc, %0" ::"r"(app_entry));
}

The compiler issues the following error:

Sources\boot_arm.c(236): error: #18: expected a ")"

this error appears on lines:

asm volatile("msr msp, %0" ::"r"(app_end_stack));
asm volatile("mov pc, %0" ::"r"(app_entry));

Apparently this problem is related to the way of inlining assembly trying to pass some parameter.

Thanks in advance for your help and thanks for sharing this project. Best regards, Yosmany.

The functions keystore_get_xxx() definitions are not generated by the keygen.exe tool
I'm just using the generate_key.bat with the following content and it generates the public and private keys as expected but doesn't add these functions:

keytools\keygen.exe --ecc256 ..\src\bootloader\src\ecc256_pub_key.c
move ecc256.der ..\src\bootloader

I stumbled upon a pointer subtraction:

Is it ok to measure an offset like that? C11 (N1570) states that the behaviour is undefined when not pointing to an array:

6.5.6 Additive operators
....
⁹ When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements.

Hi, we are updating our bootloader to use the newest version but it seems the encrypted bootloader is broken for us starting from commit b7026a5b1cbd7428eba3929a101ff198624e26c8. Right before this commit, everything seems to work fine. But on this commit (and any from this point on), our update fails.

In https://github.com/wolfSSL/wolfBoot/blob/master/docs/API.md
In trigger an update section, the function to call is wolfBoot_update(), but in wolfboot/wolfboot.h the function name is wolfBoot_update_trigger().

Hi,

I am trying to build wolfBoot on windows, but it is not straight forward. I needed to change makefile to get this going. But now I am failing on python module wolfcrypt. Does wolfcrypt is supported on windows?

In wolfBoot's README ( https://github.com/wolfSSL/wolfBoot/blob/master/README.md )
In Upgrading the firmware section, the API to call to trigger a firmware update is wolfBoot_update(), but in wolfboot/wolfboot.h and in the docs the function's name is wolfBoot_update_trigger().

The master branch does not build with wolfcrypt 5.4.0. Build returns the following error:

Traceback (most recent call last):
  File "/home/cameron/wolfBoot/tools/keytools/sign.py", line 562, in <module>
    ed = ciphers.Ed25519Private(key = wolfboot_key_buffer)
  File "/home/cameron/.local/lib/python3.10/site-packages/wolfcrypt/ciphers.py", line 1233, in __init__
    self.decode_key(key)
  File "/home/cameron/.local/lib/python3.10/site-packages/wolfcrypt/ciphers.py", line 1271, in decode_key
    raise WolfCryptError("Key decode error (%d)" % ret)
wolfcrypt.exceptions.WolfCryptError: Key decode error (-173)

wolfcrypt was installed using pip from PyPI. This error occurred using both the sim and stm32l0 examle configs.

Do those partitions have same size ? the design seems to be pretty secure. but it also takes big flash space to realize. is there any optimization on it ?

The following line in the function "keystore_add" of tools/keytools/keygen.c does not seem to be correct:
fwrite(&sl, sl.pubkey_size, 1, fpub_image);

It should be:
"fwrite(sl.pubkey, sl.pubkey_size, 1, fpub_image);"
or
"fwrite(&sl, sizeof(sl)-KEYSLOT_MAX_PUBKEY_SIZE+sl.pubkey_size, 1, fpub_image);".
Right?

Hi !
I finally got this working and was able to boot.
I tested Wolfboot and i tried to generate new keys (make keysclean make keys). I was not able to boot anymore. I found with debugger that the authenticity check fail right there:

static int keyslot_id_by_sha(const uint8_t *hint)
{
    int id = 0;
    for (id = 0; id < keystore_num_pubkeys(); id++)
    {
        key_hash(id, digest);
        if (memcmp(digest, hint, WOLFBOOT_SHA_DIGEST_SIZE) == 0)
            return id;
    }
    return -1;
}

Because the digest kept the old value (before i regenerate the keystore). Probably i missed something but i can't find anything in documentation.

I really don't know why but i had to modify a lot of Makefile to get working with RP2040. I made a fork if you want add hal/ld for rp2040 but won't work without the stage2 bootloader of pico-sdk. Feel free to contact me if you want more infos.

Support for encrypting the application image on external flash and on the fly decryption and loading to RAM on each boot.

1. Keep encrypted update on external flash.
2. Verify and decrypt partition to RAM.

I am trying to run the test app for the STM32L0 on a Nucleo-L053R8 and am experiencing a core lock up, before the application even gets into the isr_reset function. Any ideas on how to fix this?