wolfssl/wolfboot

wolfBoot is a portable, OS-agnostic, secure bootloader for microcontrollers, supporting firmware authentication and firmware update mechanisms.

wolfBoot

wolfSSL Secure Bootloader (Home page)

wolfBoot is a portable, OS-agnostic, secure bootloader solution for 32-bit microcontrollers, relying on wolfCrypt for firmware authentication, providing firmware update mechanisms.

Due to the minimalist design of the bootloader and the tiny HAL API, wolfBoot is completely independent from any OS or bare-metal application, and can be easily ported and integrated in existing embedded software projects to provide a secure firmware update mechanism.

Design based on RFC 9019 - A Firmware Update Architecture for Internet of Things.

Features

• Multi-slot partitioning of the flash device
• Integrity verification of the firmware image(s)
• Authenticity verification of the firmware image(s) using wolfCrypt's Digital Signature Algorithms (DSA)
• Minimalist hardware abstraction layer (HAL) interface to facilitate portability across different vendors/MCUs
• Copy/swap images from secondary slots into the primary slots to consent firmware update operations
• In-place chain-loading of the firmware image in the primary slot
• Support of Trusted Platform Module(TPM)
• Measured boot support, storing of the firmware image hash into a TPM Platform Configuration Register(PCR)

Components

This repository contains the following components:

• the wolfBoot bootloader
• key generator and image signing tools (requires python 3.x and wolfcrypt-py https://github.com/wolfSSL/wolfcrypt-py)
• Baremetal test applications

wolfBoot bootloader

wolfBoot is a memory-safe standalone bare-metal application, designed to run on a generic microcontroller, with no dynamic memory allocation mechanism or linkage to any standard C library besides wolfCrypt.

The bootloader consists of the following components:

• wolfCrypt, which is used to verify the signature of the images
• A minimalist Hardware Abstraction Layer, with an implementation provided for the supported target, which is in charge for IAP flash access and clock setting on the specific MCU
• The core bootloader
• A small application library used by the application to interact with the bootloader src/libwolfboot.c

Integrating wolfBoot in an existing project

Required steps

• See docs/Targets.md for reference implementation examples.
• Provide a HAL implementation for the target platform (see Hardware Abstraction Layer)
• Decide a flash partition strategy and modify include/target.h accordingly (see Flash partitions)
• Change the entry point of the firmware image to account for bootloader presence
• Equip the application with the wolfBoot library to interact with the bootloader
• Configure and compile a bootable image with a single "make" command
• For help signing firmware see wolfBoot Signing
• For enabling measured boot see wolfBoot measured boot

Examples provided

Additional examples available on our GitHub wolfBoot-examples repository here.

The following steps are automated in the default Makefile target, using the baremetal test application as an example to create the factory image. By running make, the build system will:

• Create a Ed25519 Key-pair using the ed25519_keygen tool
• Compile the bootloader. The public key generated in the step above is included in the build
• Compile the firmware image from the test application in test_app
• Re-link the firmware to change the entry-point to the start address of the primary partition
• Sign the firmware image using the ed25519_sign tool
• Create a factory image by concatenating the bootloader and the firmware image

The factory image can be flashed to the target device. It contains the bootloader and the signed initial firmware at the specified address on the flash.

The sign.py tool transforms a bootable firmware image to comply with the firmware image format required by the bootloader.

For detailed information about the firmware image format, see Firmware image

For detailed information about the configuration options for the target system, see Compiling wolfBoot

Upgrading the firmware

• Compile the new firmware image, and link it so that its entry point is at the start address of the primary partition
• Sign the firmware using the sign.py tool and the private key generated for the factory image
• Transfer the image using a secure connection, and store it to the secondary firmware slot
• Trigger the image swap using libwolfboot wolfBoot_update_trigger() function. See wolfBoot library API for a description of the operation
• Reboot to let the bootloader begin the image swap
• Confirm the success of the update using libwolfboot wolfBoot_success() function. See wolfBoot library API for a description of the operation

For more detailed information about firmware update implementation, see Firmware Update

Additional features

• Remote external flash interface
• External encrypted partitions
• Delta updates

Building

Makefile

To build using the Makefile, create a .config file with your build specifications in the wolfBoot root directory. You can find a number of examples that you can use inside config/examples. Then run make keytools to generate the signing and key generation tools. If you have wolfCrypt-py installed and would like to use it, you can skip this step.

Documentation for the flash configuration options used in .config can be found in docs/compile.md.

For example, to build using our provided stm32h7.config:

cp config/examples/stm32h7.config .config
make keytools
make

CMake

To build using CMake, create a build directory and run cmake with the target platform as well as values for the partition size and address variables. To build the test-apps, run with -DBUILD_TEST_APPS=yes. To use the wolfCrypt-py keytools, run with -DPYTHON_KEYTOOLS=yes.

For example, to build for the stm32h7 platform:

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

The output should look something like:

Scanning dependencies of target keystore
[  2%] Building signing tool
[  4%] Building keygen tool
[  7%] Generating keystore.c and signing private key
Keytype: ECC256
Gen /home/user/wolfBoot/build/wolfboot_signing_private_key.der
Generating key (type: ECC256)
Associated key file:   /home/user/wolfBoot/build/wolfboot_signing_private_key.der
Key type   :           ECC256
Public key slot:       0
Done.
[  7%] Built target keystore
Scanning dependencies of target public_key
[  9%] Building C object CMakeFiles/public_key.dir/keystore.c.o
[ 11%] Linking C static library libpublic_key.a
[ 14%] Built target public_key
Scanning dependencies of target wolfboothal
[ 16%] Building C object CMakeFiles/wolfboothal.dir/hal/stm32h7.c.o
[ 19%] Linking C static library libwolfboothal.a
[ 19%] Built target wolfboothal
Scanning dependencies of target wolfcrypt
[ 21%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/integer.c.o
[ 23%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/tfm.c.o
[ 26%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/ecc.c.o
[ 28%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/memory.c.o
[ 30%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/wc_port.c.o
[ 33%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/wolfmath.c.o
[ 35%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/hash.c.o
[ 38%] Building C object lib/CMakeFiles/wolfcrypt.dir/wolfssl/wolfcrypt/src/sha256.c.o
[ 40%] Linking C static library libwolfcrypt.a
[ 40%] Built target wolfcrypt
Scanning dependencies of target wolfboot
[ 42%] Building C object CMakeFiles/wolfboot.dir/src/libwolfboot.c.o
[ 45%] Linking C static library libwolfboot.a
[ 45%] Built target wolfboot
Scanning dependencies of target image
[ 47%] Building C object test-app/CMakeFiles/image.dir/app_stm32h7.c.o
[ 50%] Building C object test-app/CMakeFiles/image.dir/led.c.o
[ 52%] Building C object test-app/CMakeFiles/image.dir/system.c.o
[ 54%] Building C object test-app/CMakeFiles/image.dir/timer.c.o
[ 57%] Building C object test-app/CMakeFiles/image.dir/startup_arm.c.o
[ 59%] Linking C executable image
[ 59%] Built target image
Scanning dependencies of target image_signed
[ 61%] Generating image.bin
[ 64%] Signing  image
wolfBoot KeyTools (Compiled C version)
wolfBoot version 10C0000
Update type:          Firmware
Input image:          /home/user/wolfBoot/build/test-app/image.bin
Selected cipher:      ECC256
Selected hash  :      SHA256
Public key:           /home/user/wolfBoot/build/wolfboot_signing_private_key.der
Output  image:        /home/user/wolfBoot/build/test-app/image_v1_signed.bin
Target partition id : 1
Calculating SHA256 digest...
Signing the digest...
Output image(s) successfully created.
[ 64%] Built target image_signed
Scanning dependencies of target image_outputs
[ 66%] Generating image.size
   text	   data	    bss	    dec	    hex	filename
   5284	    108	     44	   5436	   153c	/home/user/wolfBoot/build/test-app/image
[ 69%] Built target image_outputs
Scanning dependencies of target wolfboot_stm32h7
[ 71%] Building C object test-app/CMakeFiles/wolfboot_stm32h7.dir/__/src/string.c.o
[ 73%] Building C object test-app/CMakeFiles/wolfboot_stm32h7.dir/__/src/image.c.o
[ 76%] Building C object test-app/CMakeFiles/wolfboot_stm32h7.dir/__/src/loader.c.o
[ 78%] Building C object test-app/CMakeFiles/wolfboot_stm32h7.dir/__/src/boot_arm.c.o
[ 80%] Building C object test-app/CMakeFiles/wolfboot_stm32h7.dir/__/src/update_flash.c.o
[ 83%] Linking C executable wolfboot_stm32h7
[ 83%] Built target wolfboot_stm32h7
Scanning dependencies of target binAssemble
[ 85%] Generating bin-assemble tool
[ 85%] Built target binAssemble
Scanning dependencies of target image_boot
[ 88%] Generating wolfboot_stm32h7.bin
[ 90%] Signing  image
wolfBoot KeyTools (Compiled C version)
wolfBoot version 10C0000
Update type:          Firmware
Input image:          /home/user/wolfBoot/build/test-app/image.bin
Selected cipher:      ECC256
Selected hash  :      SHA256
Public key:           /home/user/wolfBoot/build/wolfboot_signing_private_key.der
Output  image:        /home/user/wolfBoot/build/test-app/image_v1_signed.bin
Target partition id : 1
Calculating SHA256 digest...
Signing the digest...
Output image(s) successfully created.
[ 92%] Assembling image factory image
[ 95%] Built target image_boot
Scanning dependencies of target wolfboot_stm32h7_outputs
[ 97%] Generating wolfboot_stm32h7.size
   text	   data	    bss	    dec	    hex	filename
  42172	      0	     76	  42248	   a508	/home/user/wolfBoot/build/test-app/wolfboot_stm32h7
[100%] Built target wolfboot_stm32h7_outputs

Signing and hashing algorithms can be specified with -DSIGN=<alg> and -DHASH=<alg>. To view additional options to configuring wolfBoot, add -LAH to your cmake command, along with the partition specifications.

$ 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 -LAH ..

stm32f4

$ cmake -DWOLFBOOT_TARGET=stm32f4 -DWOLFBOOT_PARTITION_SIZE=0x20000 -DWOLFBOOT_SECTOR_SIZE=0x20000 -DWOLFBOOT_PARTITION_BOOT_ADDRESS=0x08020000 -DWOLFBOOT_PARTITION_UPDATE_ADDRESS=0x08040000 -DWOLFBOOT_PARTITION_SWAP_ADDRESS=0x08060000 ..

stm32u5

$ cmake -DWOLFBOOT_TARGET=stm32u5 -DBUILD_TEST_APPS=yes -DWOLFBOOT_PARTITION_BOOT_ADDRESS=0x08100000 -DWOLFBOOT_SECTOR_SIZE=0x2000 -DWOLFBOOT_PARTITION_SIZE=0x20000 -DWOLFBOOT_PARTITION_UPDATE_ADDRESS=0x817F000 -DWOLFBOOT_PARTITION_SWAP_ADDRESS=0x81FE000 -DNO_MPU=yes ..

stm32l0

$ cmake -DWOLFBOOT_TARGET=stm32l0 -DWOLFBOOT_PARTITION_BOOT_ADDRESS=0x8000 -DWOLFBOOT_SECTOR_SIZE=0x1000 -DWOLFBOOT_PARTITION_SIZE=0x10000 -DWOLFBOOT_PARTITION_UPDATE_ADDRESS=0x18000 -DWOLFBOOT_PARTITION_SWAP_ADDRESS=0x28000 -DNVM_FLASH_WRITEONCE=yes ..

Troubleshooting

1. Python errors when signing a key:

Traceback (most recent call last):
  File "tools/keytools/keygen.py", line 135, in <module>
    rsa = ciphers.RsaPrivate.make_key(2048)
AttributeError: type object 'RsaPrivate' has no attribute 'make_key'

Traceback (most recent call last):
  File "tools/keytools/sign.py", line 189, in <module>
    r, s = ecc.sign_raw(digest)
AttributeError: 'EccPrivate' object has no attribute 'sign_raw'

You need to install the latest wolfcrypt-py here: https://github.com/wolfSSL/wolfcrypt-py

Use pip3 install wolfcrypt.

Or to install based on a local wolfSSL installation use:

cd wolfssl
./configure --enable-keygen --enable-rsa --enable-ecc --enable-ed25519 --enable-des3 CFLAGS="-DFP_MAX_BITS=8192 -DWOLFSSL_PUBLIC_MP"
make
sudo make install

cd wolfcrypt-py
USE_LOCAL_WOLFSSL=/usr/local pip3 install .

2. Key algorithm mismatch:

The error Key algorithm mismatch. Remove old keys via 'make keysclean' indicates the current .config SIGN algorithm does not match what is in the generated src/keystore.c file. Use make keysclean to delete keys and regenerate.

Release Notes

v1.0 (2018-12-04)

• Initial release with fail-safe update, HAL support for STM32 and nRF52

V1.1 (2019-03-27)

• Added support for ECC-256 DSA
• Added support for external (e.g. SPI) flash for Update/swap
• Anti-rollback protection via version number
• Hardware support
  • Added compile options for Cortex-M0
  • new HAL: Atmel SamR21
  • new HAL: TI cc26x2
  • new HAL: NXP/Freescale Kinetis SDK
• Improved sign/update tools compatibility (windows)

V1.2 (2019-07-30)

• Added support for multiple architectures
• key generation and signing tools rewritten in python for portability
• Added compile-time option to move flash-writing functions to RAM
• Introduced the possibility for the bootloader to update itself
• Fixed compile issues on macOS and WSL
• Hardware support
  • Added RV32 RISC-V architecture
  • Added hardware-assisted dual-bank support on STM32F76x/77x
  • new HAL: RV32 FE310 (SiFive HiFive-1)
  • new HAL: STM32L0
  • new HAL: STM32G0
  • new HAL: STM32F7

V1.3 (2019-11-13)

• New configuration mechanism based on make config, helps creating and storing target-specific configurations
  • Configuration examples provided for a number of existing platforms
• fix bug in self-update mechanism when SPI flash is in use
• Introduced support for hardware-assisted signature verification, using public-key hardware accelerators
  • Added support for STM32 PKA (e.g. STM32WB55)
  • Added support for Kinetis/Freescale PKHA (e.g. Kinetis K82F)

V1.4 (2020-01-06)

• TPM2.0 support
  • Integration with wolfTPM
  • Extended STM32 SPI driver to support dual TPM/FLASH communication
  • Tested on STM32 with Infineon 9670
• RSA 2048 bit digital signature verification
• Hardware support
  • New HAL: STM32H7

V1.5 (2020-04-28)

• RSA 4096 bit digital signature verification
• SHA3
• Portable C key management tools
• Improved integration with Microsoft Windows
  • Visual Studio solution for key management tools
• Support to compile with IAR
  • Fixed incompatible code
  • added IAR example project
• New architecture: ARMv8 (64-bit)
  • ARM Cortex-A boot code compatible with TrustZone
  • Linux staging and device tree support
• External flash abstraction
  • remote update partition accessed via UART
• Hardware support
  • New HAL: raspberry-pi
  • New HAL: Xilinx Zynq+
  • New HAL: NXP LPC54xx

V1.6 (2020-08-25)

• Support for encryption of external partitions
• Support for MPU on ARM Cortex-M platforms
• Support for using an RSA signature that includes ASN.1 encoded header
• Support for bootloader updates from external flash: SPI functions can run from RAM
• Added TPM RSA verify support
• Added option to use software SHA in combination with TPM
• Fix logic in emergency updates
• Fix loop logic in bootloader update
• Fix manifest header boundary checks (prevents parser overflows)
• Improve sanity checks for aligned fields in manifest header
• Add unit tests against manifest header parser
• Fix Ed25519 signing tool
• Fix RSA keygen tool
• wolfTPM integration: improvements and bugfixes
• Fix configuration and documentation for STM32WB
• Fix alignment of trailers in NVM_FLASH_WRITEONCE mode
• Fix uint16_t index overflow on platforms with very small flash pages
• Fix for building C key tools on windows (Cygwin/MinGW/Visual Studio)
• Fix in LPC driver: correct page alignment in flash write
• Hardware support
  • New HAL: Cypress psoc6
  • Support for psoc6 Hardware crypto accelerator
  • SPI driver: Nordic nRF52

V1.7.1 (2021-02-03)

• Added support for measured boot via TPM
• Support for TZEN on Cortex-m33
• Added option to disable backup/fallback
• Added option FLAGS_HOME to store UPDATE flags in the BOOT partition
• Zynq: added support for eFuse
• Zynq: improved debugging
• Xilinx: support for BSP QSPI driver
• Updated user documentation
• Extend coverage of automatic non-regression tests running on Jenkins
• Fix wolfTPM integration: use custom settings
• Fix Fallback operations when encryption is enabled
• Fix DUALBANK mode on STM32L5xx
• Fix maximum image size check
• Fix in STM32H7 driver: workaround for error correction in flash writing
• Hardware support
  • New ARCH: ARMv8-m (Cortex-m33)
  • New HAL: STM32L5xx
  • New HAL: NXP iMX-RT1060
  • SPI driver: STM32L0x3
  • Uart driver: STM32L0x3

V1.8 (2021-07-19)

• Use SP math for RSA4096
• Updated RSA to use inline operation and disable OAEP padding
• Memory model: removed dependency on XMALLOC/XFREE for ECC and RSA operations
• Added option WOLFBOOT_SMALL_STACK with hardcoded compile-time buffers
• Added option SIGN=NONE to disable secure boot at compile time
• Fix self-update documentation
• Added test cases for configuration option combinations
• Hardware support
  • New ARCH: PowerPC
  • New ARCH: ARM Cortex-R
  • New HAL: NXP T2080
  • New HAL: TI TMS570LC435
  • STM32H7: Correct BANK2 offset

V1.9 (2021-11-09)

• Delta/incremental updates
• Fixes for key tools
• Updates IAR IDE project
• Documentation updates and fixes
  • API function names to match code
  • STM32L5 updates
• Hardware support
  • New HAL: STM32L4
  • TMS570LC43xx: Use NVM_FLASH_WRITEONCE for update progress and fix stack pointer initialization

V1.10 (2022-01-10)

• Delta updates: expanded documentation + bug fixes
• Support Ed448 for signature verification
• Hardware support:
  • Secure memory mode for STM32G0
  • Fix for STM32L5 in dual-bank mode
  • UEFI support: wolfBoot as EFI application on x86_64
  • Fixed self-update in Cortex-R5
  • Fixed HW support regressions in PSOC-6 build

V1.11 (2022-04-05)

• Mitigation against fault-injections and glitching attacks (https://www.wolfssl.com/secure-boot-glitching-attacks/)
• Support AES128 and AES256 for update encryption
• Support ECC384 signature verification
• Support SHA2-384 for image hash
• Fixed alignment of delta update fields in manifest
• Image size propagated to sign tools
• Added test automation based on renode.io and github actions
• Hardware support
  • New HAL: STM32U5
  • New HAL: NXP i.MX-RT1050
  • Fix risc-V 32bit port (missing include)
  • Fix STM32L4 (VTOR alignments; clock setting clash in libwolfboot)
  • STM32H7: improve HAL and documentation

V1.12 (2022-07-26)

• Encrypted delta updates
• Support RSA3072 signature verification
• Partition ID support to include custom additional images
• New format to store multiple public keys, using keystore
• Several fixes to keytools and IDE support
• Added new test cases
• Hardware support
  • New HAL: Simulated target for rapid tests

V1.13 (2022-11-08)

• Fixed IAR sign script
• Added support for encrypted self-update
• Support for NAII 68PPC2 with NXP T2080 on DEOS
• Fixed Xilinx QSPI support
• Fixed API usage in external flash support for SPI/UART
• Fixed bug in encrypted delta updates
• Updated wolfCrypt to wolfSSL submodule v5.5.3

V1.14 (2022-12-30)

• Added support for CMake build
• STM32U5: Support for external flash
• STM32H7: Support for QSPI flash
• Support for NXP QoriQ P1021
• Cleanups and improvements for DEOS support on t2080
• Docker tests: refactoring
• Github Actions: added build checks for most available configurations
• Updated wolfTPM to v.2.7.0
• Updated wolfCrypt to wolfSSL v.5.5.4

V1.15 (2023-04-13)

• Refactor powerfail-safe update for NVMs without consecutive write operations
• Support for SP math on AARCH64 targets
• Fixed keygen.c exported public key size
• Added more test cases and github actions
• Updated wolfSSL to v.5.6.0
• Hardware support:
  • OCTOSPI support (STM32)
  • Fixed STM32H7 UART, added UART debug
  • New HAL: Renesas RA6M4 (with IDE example projects)
  • New HAL: NXP i.MX-RT1064
  • Unified common code for NXP i.MX-RT10XX targets

V1.16 (2023-07-06)

• New formats supported
  • Added ELF/ELF64 loader
• Extended support for NXP P1021
  • eSPI support to access TPM
  • TPM root of trust
  • fixes to eLBC NAND driver
• Improvements on PowerPC architecture
  • fixed PIC execution
  • support booting from RAM
  • refactor of update_ram.c logic
  • moved wolfBoot stack to DDR after DDR initialization
• Rework of Renesas examples, adding HSM support
  • RA6M4 example project using SCE
  • RX72N example project using TSIP
  • Extended documentation
• Bug fix: fix wrong partition selection with NVM_FLASH_WRITEONCE introduced in v.1.15
• Testing: added test cases (delta + encrypt)
• Documentation: fixed several spelling errors

V 2.0.0 - (2023-11-07)

• New feature: post-quantum stateful hash-based signature schemes.
  • Support for LMS/HSS
  • Support for XMSS/XMSS^MT
• New feature: PKCS11 engine in TrustZone-M secure mode
  • wolfBoot as secure-mode supervisor on ARMv8-M
• New TPM features
  • TPM NV as root of trust
  • Password-based access to NV slots
  • Measured boot via PCR extensions
  • Sealing/unsealing NV based on externally signed PCR policy and/or password
• New architecture: x86-64bit using FSP
  • Intel FSP support
  • Integration with TPM
  • Two-stages model with support for PCI enumeration, AHCI drivers, SATA lock mechanism
  • Multiboot2/ELF payload support
• New hardware targets
  • Intel TigerLake in FSP mode
  • STM32C0
• Bug fixing: core
  • Fixed several bugs in NVM_FLASH_WRITEONCE mode
  • Fixed bugs in delta updates
• Improved support to existing targets
  • Fixed issues in TSIP project
  • Improved support for NXP QoriQ/p1021
  • Improved support for NXP T1084
  • Reworked SPI support for NXP RT1050
  • STM32L4: Fixed clock speed
  • ARMv7-m: improved assembly support for Cortex-M4
  • ARMv8-m: enabled assembly optimizations by default
• Reworked keytools and build environment
  • Improved build experience for MacOS users
  • Fix for building in windows/minGW
  • Deprecated python keytools
  • Keytools: support multiple key formats, don't assume raw keys
  • Fixed bug in delta image generation
  • Keystore improvements: support multiple key format in the same keystore
• Testing
  • Added new sets of power-failure automated tests on simulator target
  • Simulator: tests can now run on MacOS
  • Unit tests: improved coverage. Added gcov reports
  • Static analysis: added cppcheck tests, fixed all relevant warnings

V 2.0.2 - (2023-12-29)

• Fixed bug in sign tool when using ECC keys
• Improved documentation
• Added customizable DCD for NXP targets

V 2.1.0 - (2024-04-16)

• New features
  • Custom TLVs in manifest header for custom authenticated options
• Bug fixes and improvements:
  • DUALBANK: fork bootloader only once
  • Improved NO_BACKUP mode, DISABLE BACKUP mode is now powerfail-safe
  • Fault-injection mitigation: added clobbers to assembly code
  • Post-quantum algorithms: fixed build issue with conflicting wolfCrypt version
• New signature verification algorithm:
  • Added support for ECC521
• New hardware targets:
  • Microchip ATSAM-E51, including DUALBANK support
  • Renesas RZN2L
  • NXP i.MX-RT1040
  • NXP MCXA-153
• Improved support to existing targets:
  • Build fixes for TI-Hercules
  • Improved support for Integrity OS on NXP T1024
• wolfTPM integration
  • Fixes in sealing/unsealing mechanism
• Updated modules
  • wolfSSL v5.7.0
  • wolfPKCS11 v1.3.0
  • wolfTPM v3.2.0

V 2.2.0 - (2024-07-22)

• New hardware targets
  • Add STM32H5 port with support for Dual-bank, OTP, TrustZone-M
  • Add native support for Renesas RX family, using gcc toolchain
• Improvements to supported targets
  • NXP i.MX-RT:
    • New flash geometry configurations
    • Support for LPUART4
    • Add port for RT1061
    • Disable DCACHE upon flash access
    • Support for building with HAB
  • STM32:
    • Refactoring of TrustZone-M support
    • OTP driver for STM32H5/H7
    • Full firmware update demo on STM32H5
    • Add support for QSPI in STM32U5
  • Renesas RZ:
    • Add support for RSIP
  • x86-64 (FSP):
    • Improve x86-64 specific code, add features
    • Clean-up and re-arrange scripts for qemu demo
• Post-quantum crypto
  • LMS and XMSS support now using native wolfCrypt implementation
• Tools improvements
  • Keystore: now supports .der ECC key via --der
  • Add otp_primer firmware, to provision keystores in OTP
  • Add otp_gen tool to provide a pre-assembled keystore to flash into OTP
• Bug fixes
  • Fix regression in x86-EFI builds
  • Fix setting VTOR_NS when staging a non-secure app/os from TrustZone
  • Fix delta updates: patches with invalid base versions were not discarded
  • Fix potential array bound overflow in NVM_FLASH_WRITEONCE mode
  • Fix dereferencing type-punned pointer in flash update

wolfboot's Issues

Values of `version_field` and `type_field` are ignored by compiler optimization

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.

Cannot compile IAR example project

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?

Compilation error trying to use Keil uVision ARMCC Compiler

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.

i.MX RT10xx operator '*' has no right operand

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.

Compilation for cortex-M0

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 ?

External flash encrypted with Chacha broken

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.

Feature request: SEGGER RTT logging

At @Aloxy-io, we're using SEGGER RTT for logging. We've been experimenting with using that for wolfboot, too. Is this something that could be considered for inclusion? We have some proof of concept implementation that we're willing to contribute, but the dev team isn't quite sure if the licenses are compatible (we're not lawyers).

Raspberry Pi 3b hardware memory alignment issue

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.

KeyGenTool Have Some Problem

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.

support for cortex M4

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

Write firmware signing/key generator tools in python

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

Question: Does wolfBoot builds on windows?

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?

Boot flags update fail on H7 (if last sector has some data)

### Description

This issue happens in STM32H72x/3x microcontroller where it has only 1 MB of flash (hence only one bank) and Sector is 128K in size.

When code size (application) is 260 KBs or more, the memory map in linker looks like this.

Bootloader (Sector 1)
Application (sector 2-4)
Update area (sector 5-7)
Swap area (Sector 8)

So, when update FW is more than 256 KBs in size it will write last few bytes in 3rd sector (Sector 7 in case above). Which is the same sector, which has end address for FLAGS.
So, when system reboots after DFU and our update FW lies in Update Area it will erase the last sector to update FLAGS. Which is a problem since it will erase FW data which is in start of sector 7. (see HAL implementation of H7 here

Possible solution

We can use SWAP area as temp buffer where we write last few bytes of FW in sector 7. And then erase last sector, then update FLAGS (in cache) and write everything back to last sector.

Possible problem with power fail

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

STM32U5 USART drivers support

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/

API in README to trigger update

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().

Signing with Azure Key Vault

I am using the guidance available here and here in an attempt to perform signing using an EC-P256 key stored in Azure Key Vault. I am able to sign the firmware but both signature and hash fail when using the firmware.

I have an EC-P256 (SECP256R1) key that is generated and storaged in Azure Key Vault. For more info see MS Docs.

Here are the steps I am using:

## Get the Public Key from Azure Key Vault
az keyvault key download --vault-name <vault-name> -n test-signing-key -e DER -f test-signin-key_pub.der

# Add the public key to the wolfBoot keystore using `keygen -i`
./keygen --ecc256 -i public-key.der

# Generate Hash to Sign
./sign --ecc256 --sha-only --sha256 test-app/image.bin public-key.der 1

# Call an external script to submit the hash to key vault.
# This script does the following:
#   1. Read the test-app/image_v1_digest.bin
#   2. Convert to Base64 Url Safe Encoding as described in [rfc7515 Appendix C](https://datatracker.ietf.org/doc/html/rfc7515#appendix-C)
#  3. Call the Key Vault Sign endpoint
#  4. Convert the signature returned by azure to a using the base64url decoding and write to disk as test-app/image_v1.sig

# Sign the file
./sign --ecc256 --sha256 --manual-sign test-app/image.bin test-signin-key_pub.der 1 test-app/image_v1.sig

The steps above don't produce an error. Trying to run the firmware fails though. Some further investigation shows that Azure is using non-deterministic signing and they return the signature as a IEEE-P1363 signature. My simplistic understanding is this is the r and s values concatenated together.

What format does the signature need to be in to work with the sign tool?

As a debugging step I tried this same process using just openssl to do the signing but this also fails.

# Create EC key file with Public Key
openssl ecparam -name prime256v1 -genkey -noout -out my_key.pem
openssl ec -in  my_key.pem -pubout -out  my_public_key.der

# Add the public key to the wolfBoot keystore using `keygen -i`
./tools/keytools/keygen ----ecc256 -i my_public_key.der

# Generate Hash to Sign
./tools/keytools/sign ----ecc256 --sha-only --sha256 test-app/image.bin my_public_key.der 1

# Sign hash Example (here is where you would use an HSM)
openssl pkeyutl -sign -keyform der -inkey my_key.der -in test-app/image_v1_digest.bin > test-app/image_v1.sig

# Generate final signed binary
./tools/keytools/sign ----ecc256 --sha256 --manual-sign test-app/image.bin my_public_key.der 1 test-app/image_v1.sig

Any assistance you could provide on using a Cloud based HSM like Azure Key Vault would be much appreciated. I suspect the signature format from Azure is the issue but the fact that using just openssl to do the signing also fails make me think I've missed something. Thanks in advance.

BOOT, UPDATE, SWAP Partitions

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 ?

Reset keystore.der

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.

Bootloader firmware not built without test-apps / cannot reconfigure cmake build

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,

SMNG.N5

make config missing WOLFBOOT_DTS_BOOT_ADDRESS and WOLFBOOT_DTS_UPDATE_ADDRESS

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

gicv2_init_secure() crash issue with both Raspberry Pi 3b hardware and Qemu

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

IAR linking errors

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

Support for keeping application partition encrypted on external flash

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.

[doc] swap space size?

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

RZN2L - Separating App and Loader with FreeRTOS

Hi.

I have some question about RZN2L example codes.

Examples in this repository for RZN2L, the app is created with Baremetal project.

Is this example and features (Separating App and Loader) can be done with App program with FreeRTOS?

BR

Content of keystore.der generated by kengen is not correct

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?

Prevent ext_flash_decrypt_read from writing more data than requested

@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

PIC32MZ HAL

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

Pointer subtraction might be undefined

I stumbled upon a pointer subtraction:

wolfBoot/src/image.c

Line 493 in 9fc82ac

blksz = end_sha - p;

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.

`master` does not build with `wolfcrypt` 5.4.0

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.

Log to flash support

Hi,

This isn't an issue, but rather a question regarding adding support for logging output from wolfBoot_printf to flash.

The use is twofold (particularly with units in the field in mind):

• if the bootloader fails to boot any partition, we could manually scrape the flash region used for logging to see what happened
• if an application update is performed, and the new application version is either rejected by the bootloader or doesn't confirm the update, a rollback is performed. When the old application version boots again, it could scrape the flash region used for logging to see what happened

My suggestion would be to add something like the following options to the configuration file:

• WOLFBOOT_LOG_FILE_ENABLED
• WOLFBOOT_LOG_FILE_ADDRESS (needs to be aligned with WOLFBOOT_SECTOR_SIZE)
• WOLFBOOT_LOG_FILE_SIZE (needs to be a multiple of WOLFBOOT_SECTOR_SIZE)

I have the following questions:

1. Is this functionality something you'd consider accepting into wolfBoot?
2. If yes to 1., would you be able to add support?

cc @danielinux 🙂

Kind regards,
Daniel

Running WolfBoot on ST NUCLEO-F401RE

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

Device tree blob (dtb) loading is not checked for integrity?

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? :)

Uefi shell wolfssl efi

Version

Latest

Description

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

Thanks

Core lock up on STM32L0

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?

Internal flash encryption

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

Support power down protection

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

Compile error, can't find <stdlib.h>

API documentation update trigger function call

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().

Problem with ECC protected flash on STM32H743

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!