Updated index.md and readme.md:
- Removed outdated info
- Added info about newly added ports
- Fixed a few style issues.
- Rephrased a few sections.
Signed-off-by: Francesco Domenico Servidio <francesco.servidio@nordicsemi.no>
`image-trailer-size` should be mentioned instead
of `image-trailer-sectors-size` in the maximal-image-size
evaluation description.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Added sub-header for point where swap-using-scratch algorithm
is described.
Added note on the maximum image size allowed for this mode.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Image trailer might consume notable amount of image slot size.
This path adds note for emphasize that fact.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Fixed H2 title in 2nd section
Rephrased the 1st section to remove duplicate content.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
Updated security.md:
- Fixed small formatting issues
- Fixed a pair of sentences.
- Added mention to hackerone page.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
Removed outdated IRC links from index.md and readme.md.
Slightly reformatted the final links in index.md and readme.md.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
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>
Francesco Domenico Servidio