Infineon: Add cyw20829 platform, shared slot feature, json memory map, psoc6 xip
Based in 1.8.0 release of MCUBoot library
This commit adds CYW20829 Infineon platform support with following capabilities:
1. Overwrite and swap upgrade mode support
2. Multi-image with up to 4 images
3. Hardware security counter is supported for CYW20829 platform
Add XIP support for PSOC6 platform - place BOOT slot in external memory and execute it in place using SMIF in XIP mode
and some new features for Infineon devices.
1. Shared upgrade slot feature - use one shared area for upgrade slots of multiple images
2. Memory map defined using JSON file - define memory regions for bootloader and user app in conventional way using JSON file
diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock
index 7e516ad..d3acbb3 100644
--- a/docs/Gemfile.lock
+++ b/docs/Gemfile.lock
@@ -7,7 +7,7 @@
minitest (~> 5.1)
tzinfo (~> 1.1)
zeitwerk (~> 2.2, >= 2.2.2)
- addressable (2.7.0)
+ addressable (2.8.0)
public_suffix (>= 2.0.2, < 5.0)
coffee-script (2.4.1)
coffee-script-source
@@ -205,15 +205,15 @@
rb-fsevent (~> 0.10, >= 0.10.3)
rb-inotify (~> 0.9, >= 0.9.10)
mercenary (0.3.6)
- mini_portile2 (2.5.0)
+ mini_portile2 (2.6.1)
minima (2.5.1)
jekyll (>= 3.5, < 5.0)
jekyll-feed (~> 0.9)
jekyll-seo-tag (~> 2.1)
minitest (5.14.4)
multipart-post (2.1.1)
- nokogiri (1.11.2)
- mini_portile2 (~> 2.5.0)
+ nokogiri (1.12.5)
+ mini_portile2 (~> 2.6.1)
racc (~> 1.4)
octokit (4.20.0)
faraday (>= 0.9)
@@ -225,7 +225,7 @@
rb-fsevent (0.10.4)
rb-inotify (0.10.1)
ffi (~> 1.0)
- rexml (3.2.4)
+ rexml (3.2.5)
rouge (3.26.0)
ruby-enum (0.9.0)
i18n
diff --git a/docs/PORTING.md b/docs/PORTING.md
index bb7e0f9..2df9b49 100644
--- a/docs/PORTING.md
+++ b/docs/PORTING.md
@@ -69,10 +69,25 @@
## Flash Map
-The bootloader requires a `flash_map` to be able to know how the flash is
-partitioned. A `flash_map` consists of `struct flash_area` entries
-specifying the partitions, where a `flash_area` defined as follows:
+The bootloader requires to be able to address flash regions where the code
+for mcuboot and images of applications are stored, in system-agnostic way.
+For that purpose the mcuboot uses ID, which is integer (uint8_t) number
+that should uniquely identify each flash region.
+Such flash regions are served by object of `const struct flash_area` type while
+layout of these objects is gathered under `flash_map`.
+The common code of mcuboot, that is non-system specific, does not directly
+access contents of that object and never modifies it, instead it calls
+`flash_area_` API to perform any actions on that object.
+This way systems are free to implement internal logic of flash map or define
+`struct flash_area` as they wish; the only restriction is that ID should be
+uniquely tied to region characterized by device, offset and size.
+Changes to common mcuboot code should not affect system specific internals
+of flash map, on the other side system specific code, within mcuboot, is
+is not restricted from directly accessing `struct flash_area` elements.
+
+
+An implementation of `struct flash_area` may take form of:
```c
struct flash_area {
uint8_t fa_id; /** The slot/scratch identification */
@@ -82,8 +97,25 @@
uint32_t fa_size; /** The size of this sector */
};
```
+The above example of structure hold all information that is currently required
+by mcuboot, although the mcuboot will not be trying to access them directly,
+instead a system is required to provide following mandatory getter functions:
-`fa_id` is can be one of the following options:
+```c
+/*< Obtains ID of the flash area characterized by `fa` */
+int flash_area_get_id(const struct flash_area *fa);
+/*< Obtains ID of a device the flash area `fa` described region resides on */
+int flash_area_get_device_id(const struct flash_area *fa)
+/*< Obtains offset, from the beginning of a device, the flash area described
+ * region starts at */
+uint32_t flash_area_get_off(const struct flash_area *fa)
+/*< Obtains size, from the offset, of the flash area `fa` characterized region */
+uint32_t flash_area_get_size(const struct flash_area *fa)
+
+```
+
+The mcuboot common code uses following defines that should be defined by system
+specific header files and are used to identify destination of flash area by ID:
```c
/* Independent from multiple image boot */
@@ -101,7 +133,11 @@
#define FLASH_AREA_IMAGE_SECONDARY 6
```
-The functions that must be defined for working with the `flash_area`s are:
+The numbers, given above, are provided as an example and depend on system
+implementation.
+
+The main, also required, set of API functions that perform operations on
+flash characterized by `struct flash_area` objects is as follows:
```c
/*< Opens the area for use. id is one of the `fa_id`s */
diff --git a/docs/design.md b/docs/design.md
old mode 100644
new mode 100755
index a50feeb..e5e94b3
--- a/docs/design.md
+++ b/docs/design.md
@@ -3,7 +3,7 @@
- Copyright (c) 2017-2020 Linaro LTD
- Copyright (c) 2017-2019 JUUL Labs
- - Copyright (c) 2019-2020 Arm Limited
+ - Copyright (c) 2019-2021 Arm Limited
- Original license:
@@ -96,6 +96,8 @@
* Image header flags.
*/
#define IMAGE_F_PIC 0x00000001 /* Not supported. */
+#define IMAGE_F_ENCRYPTED_AES128 0x00000004 /* Encrypted using AES128. */
+#define IMAGE_F_ENCRYPTED_AES256 0x00000008 /* Encrypted using AES256. */
#define IMAGE_F_NON_BOOTABLE 0x00000010 /* Split image app. */
#define IMAGE_F_RAM_LOAD 0x00000020
@@ -110,7 +112,8 @@
#define IMAGE_TLV_RSA3072_PSS 0x23 /* RSA3072 of hash output */
#define IMAGE_TLV_ED25519 0x24 /* ED25519 of hash output */
#define IMAGE_TLV_ENC_RSA2048 0x30 /* Key encrypted with RSA-OAEP-2048 */
-#define IMAGE_TLV_ENC_KW128 0x31 /* Key encrypted with AES-KW-128 */
+#define IMAGE_TLV_ENC_KW 0x31 /* Key encrypted with AES-KW-128 or
+ 256 */
#define IMAGE_TLV_ENC_EC256 0x32 /* Key encrypted with ECIES-P256 */
#define IMAGE_TLV_ENC_X25519 0x33 /* Key encrypted with ECIES-X25519 */
#define IMAGE_TLV_DEPENDENCY 0x40 /* Image depends on other image */
@@ -269,13 +272,26 @@
#define IMAGE_EXECUTABLE_RAM_SIZE <area_size_in_bytes>
```
+For multiple image load if multiple ram regions are used platform must define
+the `MULTIPLE_EXECUTABLE_RAM_REGIONS` flag instead and implement the following
+function:
+
+```c
+int boot_get_image_exec_ram_info(uint32_t image_id,
+ uint32_t *exec_ram_start,
+ uint32_t *exec_ram_size)
+```
+
When ram-load is enabled, the `--load-addr <addr>` option of the `imgtool`
script must also be used when signing the images. This option set the `RAM_LOAD`
flag in the image header which indicates that the image should be loaded to the
RAM and also set the load address in the image header.
-The ram-load mode currently supports only the single image boot and the image
-encryption feature is not supported.
+When the encryption option is enabled (`MCUBOOT_ENC_IMAGES`) along with ram-load
+the image is checked for encryption. If the image is not encrypted, RAM loading
+happens as described above. If the image is encrypted, it is copied in RAM at
+the provided address and then decrypted. Finally, the decrypted image is
+authenticated in RAM and executed.
## [Boot Swap Types](#boot-swap-types)
@@ -335,14 +351,14 @@
### [Revert mechanism in direct-xip mode](#direct-xip-revert)
The direct-xip mode also supports a "revert" mechanism which is the equivalent
-of the swap mode's "revert" swap. It can be enabled with the
-MCUBOOT_DIRECT_XIP_REVERT config option and an image trailer must also be added
-to the signed images (the "--pad" option of the `imgtool` script must be used).
-For more information on this please read the [Image Trailer](#image-trailer)
-section and the [imgtool](imgtool.md) documentation. Making the images permanent
-(marking them as confirmed in advance) is also supported just like in swap mode.
-The individual steps of the direct-xip mode's "revert" mechanism are the
-following:
+of the swap mode's "revert" swap. When the direct-xip mode is selected it can be
+enabled with the MCUBOOT_DIRECT_XIP_REVERT config option and an image trailer
+must also be added to the signed images (the "--pad" option of the `imgtool`
+script must be used). For more information on this please read the
+[Image Trailer](#image-trailer) section and the [imgtool](imgtool.md)
+documentation. Making the images permanent (marking them as confirmed in
+advance) is also supported just like in swap mode. The individual steps of the
+direct-xip mode's "revert" mechanism are the following:
1. Select the slot which holds the newest potential image.
2. Was the image previously selected to run (during a previous boot)?
@@ -426,7 +442,7 @@
either decreasing this size, to limit RAM usage, or to increase it in devices
that have massive amounts of Flash or very small sized sectors and thus require
a bigger configuration to allow for the handling of all slot's sectors.
-The factor of min-write-sz is due to the behavior of flash hardware. The factor
+The factor of min-write-size is due to the behavior of flash hardware. The factor
of 3 is explained below.
2. Encryption keys: key-encrypting keys (KEKs). These keys are needed for
@@ -689,6 +705,41 @@
+ Boot into image in the primary slot of the 0th image position\
(other image in the boot chain is started by another image).
+### [Multiple Image Boot for RAM loading and direct-xip](#multiple-image-boot-for-ram-loading-and-direct-xip)
+
+The operation of the boot loader is different when the ram-load or the
+direct-xip strategy is chosen. The flash map is very similar to the swap
+strategy but there is no need for Scratch area.
+
++ Loop 1. Until all images are loaded and all dependencies are satisfied
+ 1. Subloop 1. Iterate over all images
+ + Does any of the slots contain an image?
+ + Yes:
+ + Choose the newer image.
+ + Copy it to RAM in case of ram-load strategy.
+ + Validate the image (integrity and security check).
+ + If validation fails delete the image from flash and try the other
+ slot. (Image must be deleted from RAM too in case of ram-load
+ strategy.)
+ + No: Return with failure.
+
+ 2. Subloop 2. Iterate over all images
+ + Does the current image depend on other image(s)?
+ + Yes: Are all the image dependencies satisfied?
+ + Yes: Skip to next image.
+ + No:
+ + Delete the image from RAM in case of ram-load strategy, but
+ do not delete it from flash.
+ + Try to load the image from the other slot.
+ + Restart dependency check from the first image.
+ + No: Skip to next image.
+
++ Loop 2. Iterate over all images
+ + Increase the security counter if needed.
+ + Do the measured boot and the data sharing if needed.
+
++ Boot the loaded slot of image 0.
+
## [Image Swapping](#image-swapping)
The boot loader swaps the contents of the two image slots for two reasons:
@@ -973,8 +1024,8 @@
If you want to enable and use encrypted images, see:
[encrypted_images](encrypted_images.md).
-Note: Image encryption is not supported when the direct-xip or the ram-load
-upgrade strategy is selected.
+Note: Image encryption is not supported when the direct-xip upgrade strategy
+is selected.
### [Using Hardware Keys for Verification](#hw-key-support)
@@ -1264,6 +1315,7 @@
are issued from the MCUboot source directory):
```sh
+$ mkdir docker
$ ./ci/fih-tests_install.sh
$ FIH_LEVEL=MCUBOOT_FIH_PROFILE_MEDIUM BUILD_TYPE=RELEASE SKIP_SIZE=2 \
DAMAGE_TYPE=SIGNATURE ./ci/fih-tests_run.sh
@@ -1285,4 +1337,4 @@
the shell returns, and it is possible to investigate the results. It is also
possible to stop the test with _Ctrl+c_. The parameters to the
`execute_test.sh` are `SKIP_SIZE`, `BUILD_TYPE`, `DAMAGE_TYPE`, `FIH_LEVEL` in
- order.
\ No newline at end of file
+ order.
diff --git a/docs/encrypted_images.md b/docs/encrypted_images.md
index 74443db..838f493 100644
--- a/docs/encrypted_images.md
+++ b/docs/encrypted_images.md
@@ -59,9 +59,9 @@
that the encrypted flag is set and TLV data is OK, then it decrypts each
image block before sending the data to the hash routines.
-The image is encrypted using AES-CTR-128, with a counter that starts
-from zero (over the payload blocks) and increments by 1 for each 16-byte
-block. AES-CTR-128 was chosen for speed/simplicity and allowing for any
+The image is encrypted using AES-CTR-128 or AES-CTR-256, with a counter
+that starts from zero (over the payload blocks) and increments by 1 for each
+16-byte block. AES-CTR was chosen for speed/simplicity and allowing for any
block to be encrypted/decrypted without requiring knowledge of any other
block (allowing for simple resume operations on swap interruptions).
@@ -70,14 +70,15 @@
but randomizing a 16-byte block with a TRNG should make it highly
improbable that duplicates ever happen.
-To distribute this AES-CTR-128 key, new TLVs were defined. The key can be
-encrypted using either RSA-OAEP, AES-KW-128, ECIES-P256 or ECIES-X25519.
+To distribute this AES-CTR key, new TLVs were defined. The key can be
+encrypted using either RSA-OAEP, AES-KW (128 or 256 bits depending on the
+AES-CTR key length), ECIES-P256 or ECIES-X25519.
For RSA-OAEP a new TLV with value `0x30` is added to the image, for
-AES-KW-128 a new TLV with value `0x31` is added to the image, for
+AES-KW a new TLV with value `0x31` is added to the image, for
ECIES-P256 a new TLV with value `0x32` is added, and for ECIES-X25519 a
newt TLV with value `0x33` is added. The contents of those TLVs
-are the results of applying the given operations over the AES-CTR-128 key.
+are the results of applying the given operations over the AES-CTR key.
## [ECIES encryption](#ecies-encryption)
@@ -94,17 +95,17 @@
* Derive the new keys from the secret using HKDF (built on HMAC-SHA256). We
are not using a `salt` and using an `info` of `MCUBoot_ECIES_v1`, generating
48 bytes of key material.
-* A new random encryption key of 16 bytes is generated (for AES-128). This is
+* A new random encryption key is generated (for AES). This is
the AES key used to encrypt the images.
-* The key is encrypted with AES-128-CTR and a `nonce` of 0 using the first
- 16 bytes of key material generated previously by the HKDF.
+* The key is encrypted with AES-128-CTR or AES-256-CTR and a `nonce` of 0 using
+ the first 16 bytes of key material generated previously by the HKDF.
* The encrypted key now goes through a HMAC-SHA256 using the remaining 32
bytes of key material from the HKDF.
The final TLV is built from the 65 bytes for ECIES-P256 or 32 bytes for
ECIES-X25519, which correspond to the ephemeral public key, followed by the
-32 bytes of MAC tag and the 16 bytes of the encrypted key, resulting in a TLV
-of 113 bytes for ECIES-P256 or 80 bytes for ECIES-X25519.
+32 bytes of MAC tag and the 16 or 32 bytes of the encrypted key, resulting in
+a TLV of 113 or 129 bytes for ECIES-P256 and 80 or 96 bytes for ECIES-X25519.
The implemenation of ECIES-P256 is named ENC_EC256 in the source code and
artifacts while ECIES-X25519 is named ENC_X25519.
@@ -149,7 +150,7 @@
`imgtool getpub -k <input.pem> -l <lang>`, where lang can be one of `c` or
`rust` (defaults to `c`).
-If using AES-KW-128, follow the steps in the next section to generate the
+If using AES-KW, follow the steps in the next section to generate the
required keys.
## [Creating your keys with Unix tooling](#creating-your-keys-with-unix-tooling)
@@ -161,5 +162,6 @@
* If using ECIES-X25519, generate a private key passing the option `-t x25519`
to `imgtool keygen` command. To generate public key PEM file the following
command can be used: `openssl pkey -in <generated-private-key.pem> -pubout`
-* If using AES-KW-128 (`newt` only), the `kek` can be generated with a
- command like `dd if=/dev/urandom bs=1 count=16 | base64 > my_kek.b64`
+* If using AES-KW (`newt` only), the `kek` can be generated with a
+ command like (change count to 32 for a 256 bit key)
+ `dd if=/dev/urandom bs=1 count=16 | base64 > my_kek.b64`
diff --git a/docs/index.md b/docs/index.md
index 5f2cf09..c892c57 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -61,13 +61,13 @@
For more information in the source, here are some pointers:
-- [boot/bootutil](https://github.com/mcu-tools/mcuboot/tree/master/boot/bootutil): The core of the bootloader itself.
-- [boot/boot\_serial](https://github.com/mcu-tools/mcuboot/tree/master/boot/boot_serial): Support for serial upgrade within the bootloader itself.
-- [boot/zephyr](https://github.com/mcu-tools/mcuboot/tree/master/boot/zephyr): Port of the bootloader to Zephyr
-- [boot/mynewt](https://github.com/mcu-tools/mcuboot/tree/master/boot/mynewt): Mynewt bootloader app
-- [boot/mbed](https://github.com/mcu-tools/mcuboot/tree/master/boot/mbed): Port of the bootloader to Mbed-OS
-- [imgtool](https://github.com/mcu-tools/mcuboot/tree/master/scripts/imgtool.py): A tool to securely sign firmware images for booting by MCUboot.
-- [sim](https://github.com/mcu-tools/mcuboot/tree/master/sim): A bootloader simulator for testing and regression
+- [boot/bootutil](https://github.com/mcu-tools/mcuboot/tree/main/boot/bootutil): The core of the bootloader itself.
+- [boot/boot\_serial](https://github.com/mcu-tools/mcuboot/tree/main/boot/boot_serial): Support for serial upgrade within the bootloader itself.
+- [boot/zephyr](https://github.com/mcu-tools/mcuboot/tree/main/boot/zephyr): Port of the bootloader to Zephyr
+- [boot/mynewt](https://github.com/mcu-tools/mcuboot/tree/main/boot/mynewt): Mynewt bootloader app
+- [boot/mbed](https://github.com/mcu-tools/mcuboot/tree/main/boot/mbed): Port of the bootloader to Mbed-OS
+- [imgtool](https://github.com/mcu-tools/mcuboot/tree/main/scripts/imgtool.py): A tool to securely sign firmware images for booting by MCUboot.
+- [sim](https://github.com/mcu-tools/mcuboot/tree/main/sim): A bootloader simulator for testing and regression
## Joining
diff --git a/docs/readme-espressif.md b/docs/readme-espressif.md
new file mode 100644
index 0000000..fa72fb3
--- /dev/null
+++ b/docs/readme-espressif.md
@@ -0,0 +1,70 @@
+# Building and using MCUboot with Espressif's chips
+
+The Espressif port is build on top of ESP-IDF HAL, therefore it is required in order to build MCUboot for Espressif SoCs.
+
+Documentation about the MCUboot bootloader design, operation and features can be found in the [design document](design.md).
+
+## SoC support availability
+
+The current port is available for use in the following SoCs within the OSes:
+- ESP32
+ - Zephyr RTOS - _WIP_
+ - NuttX
+- ESP32-S2
+ - Zephyr RTOS - _WIP_
+ - NuttX - _WIP_
+
+## Installing Requirements and Dependencies
+
+1. Install additional packages required for development with MCUboot:
+
+```
+ cd ~/mcuboot # or to your directory where mcuboot is cloned
+ pip3 install --user -r scripts/requirements.txt
+```
+
+2. Update the submodules needed by the Espressif port. This may take a while.
+
+```
+git submodule update --init --recursive --checkout boot/espressif/hal/esp-idf
+```
+
+3. Next, get the mbedtls submodule required by MCUboot.
+```
+git submodule update --init --recursive ext/mbedtls
+```
+
+4. Now we need to install IDF dependencies and set environment variables. This step may take some time:
+```
+cd boot/espressif/hal/esp-idf
+./install.sh
+. ./export.sh
+cd ../..
+```
+
+## Building the bootloader itself
+
+The MCUboot Espressif port bootloader is built using the toolchain and tools provided by ESP-IDF. Additional configuration related to MCUboot features and slot partitioning may be made using the `bootloader.conf`.
+
+**Note:** Replace `<target>` with the target ESP32 family (like `esp32`, `esp32s2` and others).
+
+1. Compile and generate the ELF:
+
+```
+cmake -DCMAKE_TOOLCHAIN_FILE=tools/toolchain-<target>.cmake -DMCUBOOT_TARGET=<target> -B build -GNinja
+cmake --build build/
+```
+
+2. Convert the ELF to the final bootloader image, ready to be flashed:
+
+```
+esptool.py --chip <target> elf2image --flash_mode dio --flash_freq 40m -o build/mcuboot_<target>.bin build/mcuboot_<target>.elf
+```
+
+3. Flash MCUboot in your board:
+
+```
+esptool.py -p <PORT> -b <BAUD> --before default_reset --after hard_reset --chip <target> write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 build/mcuboot_<target>.bin
+```
+
+You may adjust the port `<PORT>` (like `/dev/ttyUSB0`) and baud rate `<BAUD>` (like `2000000`) according to the connection with your board.
diff --git a/docs/readme-mbed.md b/docs/readme-mbed.md
index 189c7bf..2162678 100644
--- a/docs/readme-mbed.md
+++ b/docs/readme-mbed.md
@@ -16,7 +16,7 @@
* `"mcuboot.max-img-sectors"`: maximum number of sectors, should be at least the number of sectors in each slot
* `"target.restrict_size"`: the maximum size of the bootloader, such that it does not overlap with the primary slot
-More configurations such as signing algorithm, slot swapping, etc. can be found in [mbed_lib.json](https://github.com/mcu-tools/mcuboot/tree/master/boot/mbed/mbed_lib.json). Please note that certain features are not currently supported.
+More configurations such as signing algorithm, slot swapping, etc. can be found in [mbed_lib.json](https://github.com/mcu-tools/mcuboot/tree/main/boot/mbed/mbed_lib.json). Please note that certain features are not currently supported.
### Providing a secondary slot
diff --git a/docs/readme-nuttx.md b/docs/readme-nuttx.md
new file mode 100644
index 0000000..1c06964
--- /dev/null
+++ b/docs/readme-nuttx.md
@@ -0,0 +1,52 @@
+# MCUboot port for NuttX
+
+## Description
+
+The NuttX port of MCUboot secure boot library expects that the platform provides a Flash storage with the following partitions:
+- `CONFIG_MCUBOOT_PRIMARY_SLOT_PATH`: MTD partition for the application firmware image PRIMARY slot;
+- `CONFIG_MCUBOOT_SECONDARY_SLOT_PATH`: MTD partition for the application firmware image SECONDARY slot;
+- `CONFIG_MCUBOOT_SCRATCH_PATH`: MTD partition for the Scratch area;
+
+Also, these are optional features that may be enabled:
+
+- `CONFIG_MCUBOOT_WATCHDOG`: If `CONFIG_WATCHDOG` is enabled, MCUboot shall reset the watchdog timer indicated by `CONFIG_MCUBOOT_WATCHDOG_DEVPATH` to the current timeout value, preventing any imminent watchdog timeouts.
+
+The porting layer of MCUboot library consists of the following interfaces:
+- `<flash_map_backend/flash_map_backend.h>`, for enabling MCUboot to manage the application firmware image slots in the device storage.
+- `<mcuboot_config/mcuboot_config.h>`, for configuration of MCUboot's features.
+- `<mcuboot_config/mcuboot_logging.h>`, for providing logging capabilities.
+- `<os/os_malloc.h>`, for providing MCUboot access to the OS memory management interfaces.
+- `<sysflash/sysflash.h>`, for configuration of the system's flash area organization.
+
+The NuttX port of MCUboot is implemented at application-level and requires minimal knowledge about characteristics of the underlying storage device. This is achieved by means of the `BCH` and `FTL` subsystems, which enable MCUboot to manage MTD partitions via character device drivers using standard POSIX filesystem operations (e.g. `open()` / `close()` / `read()` / `write()`).
+
+## Creating MCUboot-compatible application firmware images
+
+One common use case for MCUboot is to integrate it to a firmware update agent, which is an important component of a secure firmware update subsystem. Through MCUboot APIs an application is able to install a newly received application firmware image and, once this application firmware image is assured to be valid, the application may confirm it as a stable image. In case that application firmware image is deemed bogus, MCUboot provides an API for invalidating that update, which will induce a rollback procedure to the most recent stable application firmware image.
+
+The `CONFIG_MCUBOOT_UPDATE_AGENT_EXAMPLE` example demonstrates this workflow by downloading an application firmware image from a webserver, installing it and triggering the firmware update process for the next boot after a system reset. There is also the `CONFIG_MCUBOOT_SLOT_CONFIRM_EXAMPLE`, which is a fairly simple example that just calls an MCUboot API for confirming the executing application firmware image as stable.
+
+## Using MCUboot on NuttX as a secure boot solution
+
+NuttX port for MCUboot also enables the creation of a secure bootloader application requiring minimal platform-specific implementation. The logical implementation for the secure boot is performed at application-level by the MCUboot library. Once MCUboot validates the application firmware image, it delegates the loading and execution of the application firmware image to a platform-specific routine, which is accessed via `boardctl(BOARDIOC_BOOT_IMAGE)` call. Each platform must then provide an implementation for the `board_boot_image()` for executing the required actions in order to boot a new application firmware image (e.g. deinitialize peripherals, load the Program Counter register with the application firmware image entry point address).
+
+The MCUboot bootloader application may be enabled by selecting the `CONFIG_MCUBOOT_BOOTLOADER` option.
+
+## Assumptions
+
+### IOCTL MTD commands
+
+The implementation of `<flash_map_backend/flash_map_backend.h>` expects that the MTD driver for a given image partition handles the following `ioctl` commands:
+- `MTDIOC_GEOMETRY`, for retrieving information about the geometry of the MTD, required for the configuration of the size of each flash area.
+- `MTDIOC_ERASESTATE`, for retrieving the byte value of an erased cell of the MTD, required for the implementation of `flash_area_erased_val()` interface.
+
+### Write access alignment
+
+Through `flash_area_align()` interface MCUboot expects that the implementation provides the shortest data length that may be written via `flash_area_write()` interface. The NuttX implementation passes through the `BCH` and `FTL` layers, which appropriately handle the write alignment restrictions of the underlying MTD. So The NuttX implementation of `flash_area_align()` is able to return a fixed value of 1 byte, even if the MTD does not support byte operations.
+
+## Limitations
+
+### `<flash_map_backend/flash_map_backend.h>` functions are not multitasking-safe
+
+MCUboot's documentation imposes no restrictions regarding the usage of its public interfaces, which doesn't mean they are thread-safe.
+But, regarding NuttX implementation of the `<flash_map_backend/flash_map_backend.h>`, it is safe to state that they are **not** multitasking-safe. NuttX implementation manages the MTD partitions via character device drivers. As file-descriptors cannot be shared between different tasks, if one task calls `flash_area_open` and another task calls `flash_area_<read/write/close>` passing the same `struct flash_area` instance, it will result in failure.
diff --git a/docs/release-notes.md b/docs/release-notes.md
index 172c934..885fe31 100644
--- a/docs/release-notes.md
+++ b/docs/release-notes.md
@@ -3,6 +3,44 @@
- Table of Contents
{:toc}
+## Version 1.8.0
+
+The 1.8.0 release of MCUboot contains numerous fixes, and adds support
+for the NuttX RTOS, and the Espressif ESP32 SDK.
+
+### About this release
+
+- Add support for the NuttX RTOS.
+- Add support for the Espressif ESP32 SDK.
+- `boot_serial` changed to use cddl-gen, which removes the dependency
+ on tinycbor.
+- Add various hooks to be able to change how image data is accessed.
+- Cypress supports Mbed TLS for encryption.
+- Support using Mbed TLS for ECDSA. This can be useful if Mbed TLS is
+ brought in for another reason.
+- Add simulator support for testing direct-XIP and ramload.
+- Support Mbed TLS 3.0. Updates the submodule for Mbed TLS to 3.0.
+- Enable direct-xip mode in mbed-os port.
+- extract `bootutil_public` library, a common interface for mcuboot
+ and the application.
+- Allow to boot primary image if secondary one is unreachable.
+- Add AES256 image encryption support.
+- Add Multiimage boot for direct-xip and ram-load mode.
+- Cargo files moved to top level, now `cargo test` can be run from the
+ top level directory.
+- Fault injection tests use updated TF-M.
+- Thingy:53 now supports multi-image DFU.
+- ram load and image encryption can be used together, allowing the
+ entire contents of flash to always remain encrypted.
+
+### Security fixes
+
+- [GHSA-gcxh-546h-phg4](https://github.com/mcu-tools/mcuboot/security/advisories/GHSA-gcxh-546h-phg4)
+ has been published. There is not a fix at this time, but a caution
+ to be sure to follow the instructions carefully, and make sure that
+ the development keys in the repo are never used in a production
+ system.
+
## Version 1.7.0
The 1.7.0 release of MCUBoot adds support for the Mbed-OS platform,
@@ -39,7 +77,7 @@
### Zephyr-RTOS Compatibility
-This release of MCUboot works with the Zephyr "master" at the time of the
+This release of MCUboot works with the Zephyr "main" at the time of the
release. It was tested as of has 7a3b253ce. This version of MCUboot also
works with the Zephyr v2.4.0, however it is recommended to enable
`CONFIG_MCUBOOT_CLEANUP_ARM_CORE` while using that version.
@@ -75,7 +113,7 @@
### Zephyr-RTOS Compatibility
-This release of MCUboot works the Zephyr "master" at the time of the
+This release of MCUboot works the Zephyr "main" at the time of the
release. It was tested as of has 1a89ca1238. When Zephyr v2.3.0 is
released, there will be a possible 1.6.1 or similar release of Zephyr
if needed to address any issues. There also may be branch releases of
@@ -145,7 +183,7 @@
The 1.3.1 release of MCUboot consists mostly of small bug fixes and updates.
There are no breaking changes in functionality. This release should work with
-Mynewt 1.6.0 and up, and any Zephyr `master` after sha
+Mynewt 1.6.0 and up, and any Zephyr `main` after sha
f51e3c296040f73bca0e8fe1051d5ee63ce18e0d.
### About this release
diff --git a/docs/release.md b/docs/release.md
index ff00cec..90c32b5 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -32,7 +32,7 @@
time, and allow testing to happen.
During the time between rc1 and the final release, the only changes
-that should be merged into master are those to fix bugs found in the
+that should be merged into main are those to fix bugs found in the
rc and Mynewt metadata as described in the next section.
## imgtool release
@@ -81,7 +81,7 @@
At this point, the tag can be pushed to github to make the actual
release happen:
``` bash
-git push origin HEAD:refs/heads/master
+git push origin HEAD:refs/heads/main
git push origin va.b.c-rcn
```