This patch adds the possibility to boot using ram-load with an
encrypted image. This is enabled when both the flags MCUBOOT_RAM_LOAD
and MCUBOOT_ENC_IMAGES are defined.
Signed-off-by: Fabio Utzig <utzig@apache.org>
Signed-off-by: Hugo L'Hostis <hugo.lhostis@arm.com>
Signed-off-by: Salome Thirot <salome.thirot@arm.com>
Change-Id: I7756c2c634d90a2e726117d6cfc5650653cf1b51
The commit removes requirement that each system should exactly
follow proposed layout of struct flash_area and adds information
of flash_area API being extended by getter function that access
information inside flash_area type objects, allowing systems freedom
in internal implementation of flash_area.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
To avoid potential errors caused by misconfiguration make sure the
conditionally compiled snippets of code surrounded by the
MCUBOOT_DIRECT_XIP_REVERT macro are only used when direct-xip mode
is selected.
Change-Id: I6178d8186a7ca05887bc7590f5fa0c8f83f3d731
Signed-off-by: David Vincze <david.vincze@arm.com>
Multiple image boot support is implemented for direct-xip and ram-load
strategies. Dependency checking is also added, and for ram-load more
executable ram regions can be set.
Wrapper functions are intoduced to all boot strategies.
Change-Id: I59b346277dcb2c17cef4800f1e556b4ea9144845
Signed-off-by: Mark Horvath <mark.horvath@arm.com>
Addresses CVE-2021-28834
https://github.com/advisories/GHSA-52p9-v744-mwjj
Also removed the explicit jekyll dependency, which according to the
instructions should be commented out if the github-pages dependency is
used.
Signed-off-by: David Brown <david.brown@linaro.org>
Update the main webpage to contain links to the wiki page docs on the
project charter, and the membership page.
Signed-off-by: David Brown <david.brown@linaro.org>
The internal functions of mcuboot are not consistent in opening/closing flash areas and sometimes nested calls happen to `flash_area_open` and `flash_area_close`. With the previous implementation, a nested call to `flash_area_close` would deinitialize the underlying `BlockDevice`. This could cause subsequent flash operations on an "open" flash area to fail.
This PR adds a simple open counter for each flash area and ensures the underlying `BlockDevice` is initialized and deinitialized appropriately. The `BlockDevice` is only initialized when transitioning from an open count of 0 to 1. The `BlockDevice` is only deinitialized when the open count falls to 0.
Signed-off-by: George Beckstein <becksteing@embeddedplanet.com>
Update version fields for 1.7.0 release.
Added compatibility note for zephyr-rtos.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
This PR provides a porting layer implementation and framework for building an mcuboot-based bootloader with Mbed-OS. Some symbols are not provided by the Mbed-OS port within mcuboot, namely:
- The secondary storage device (see below)
- The signing keys
- The encryption keys, if used
Use of this port is demonstrated by the following projects:
- https://github.com/AGlass0fMilk/mbed-mcuboot-demo (a complete mcuboot/Mbed-OS-based bootloader)
- https://github.com/AGlass0fMilk/mbed-mcuboot-blinky (example showing how to make an Mbed-OS application that is bootable by mcuboot)
Memory porting implementation:
The underlying implemenation uses Mbed's BlockDevice API as the storage backend for mcuboot's memory operations. This provides a very flexible way of configuring the location and layout of the secondary flash storage area. To build an mcuboot-based bootloader with Mbed-OS, the user must implement a hook function, mbed::BlockDevice* get_secondary_bd(), to provide the secondary BlockDevice that mcuboot will use.
The signing and encryption keys must also be provided by the user. They can be generated using the existing imgtool utility in the same manner used by Zephyr. There are no automated build steps currently provided by Mbed-OS to sign/encrypt build artifacts.
Known limitations:
The update candidate encryption features have not yet been fully tested. A truly secure implementation will require integration with Mbed's TRNG API in the future to inhibit side-channel attacks on the decryption process.
The TinyCrypt backend is currently only supported for Mbed-OS builds when building with the GCC toolchain. The new cmake-based Mbed-OS build system will fix the underlying issue (file name uniqueness).
Signed-off-by: George Beckstein <becksteing@embeddedplanet.com>
Signed-off-by: Evelyne Donnaes <evelyne.donnaes@arm.com>
Signed-off-by: Lingkai Dong <lingkai.dong@arm.com>
Co-authored-by: Lingkai Dong <lingkai.dong@arm.com>
Co-authored-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
The 'revert' mechanism in direct-xip is similar to the one in swap mode.
It requires the trailer magic to be added to the signed image. When a
reboot happens without the image being confirmed at runtime (without the
image_ok flag being set), the bootloader considers the image faulty and
erases it. After this it will attempt to boot the previous image
instead. The images can also be made permanent (marked as confirmed in
advance) just like in swap mode.
Change-Id: Ibde9361d4a7302dd8efbb277b691b71eca0ca877
Signed-off-by: David Vincze <david.vincze@linaro.org>
Some design.md content is causing build errors when they are included
in a .rst based documentation tree in Sphinx.
Adjust the format to make it work in both systems.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Remove a footnote that is not generating a proper link and add an inline
link to the mbed TLS referece for platform.h. This also fixes a warning
when running through recommonmark==0.6.0 because it is unable to parse the
old syntax.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
This patch introduces the ram-load mode in addition to the other
upgrade modes (swap strategies, overwrite-only, direct-XIP). When
ram-load is enabled with the MCUBOOT_RAM_LOAD option, mcuboot
selects the newest valid image based on the image version numbers from
the image header, thereafter the selected image loaded to the RAM and
executed from there. Load address is extracted from the image header.
Therefore the images must be linked to the RAM memory region.
The ram-load mode is very similar to the direct-XIP mode, main
difference is to load the newest image to the RAM beforehand the
authentication and execution. Similar to direct-XIP mode either
of the primary and the secondary slots can hold the active image.
Ram-load can be useful in case of a bit more powerful SoC, which
is not constrained in terms of internal RAM. It could be that image
is stored in external and therefore untrusted flash. Loading image
to internal (trusted) RAM is essential from the security point
of view the system. Furthermore execution from internal RAM is much
faster than from external flash.
This patch is based on the RAM_LOADING upgrade strategy which was
first introduced in the Trusted Firmware-M project.
Source TF-M version: TF-Mv1.0.
Change-Id: I95f02ff07c1dee51244ac372284f449c2efab362
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
This patch introduces the direct execute-in-place (XIP) mode in addition
to the other upgrade modes (swap strategies, overwrite-only). When
direct-XIP is enabled with the MCUBOOT_DIRECT_XIP option, mcuboot
selects the newest valid image based on the image version numbers from
the image header, thereafter the selected image runs directly from its
flash partition (slot) instead of moving it. Therefore the images must
be linked to be executed from the given image slot. It means that in
direct-XIP mode either of the primary and the secondary slots can hold
the active image.
This patch is based on the NO_SWAP upgrade strategy which was first
introduced in the Trusted Firmware-M project.
Source TF-M version: TF-Mv1.0.
Change-Id: If584cf01ae5aa7208845f6a6fa206f0595e0e61e
Signed-off-by: David Vincze <david.vincze@linaro.org>
Update various version fields. Also include a note in the release notes
describing Zephyr compatibility.
Signed-off-by: David Brown <david.brown@linaro.org>
Hugo L'Hostis