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>
To make contributions easier, place explicit copyrights by the major
contributors, along with an SPDX license identifier. Files that came
from the mynewt project, which was an Apache project will retain the
Apache project license text, although this does not apply to new
contributions, which are being made by individual contributors.
Hopefully, this will keep everyone happy, but allow contributors that
need to add an explicit copyright to have a place they can add that.
Fixes#501
Signed-off-by: David Brown <david.brown@linaro.org>
- Update documentation of 'HW based downgrade prevention'
- Add description for the following features:
MCUBOOT_MEASURED_BOOT
MCUBOOT_DATA_SHARING
MCUBOOT_HW_KEY
Change-Id: If7247e906de3028d44cdd9d14a5004661fb955af
Signed-off-by: David Vincze <david.vincze@linaro.org>
With the merge of https://github.com/apache/mynewt-newt/pull/365 `newt`
does not use `version.yml` files anymore, so remove the file and
references to updating it in the release process.
Testing a MCUBoot release now depends on `newt` `master` or `> 1.7.0`
(to be released).
Signed-off-by: Fabio Utzig <utzig@apache.org>
This description is needed to explain why MCUBoot won't
revert a recently performed update.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
- Add image security counter verification (read security counter value
from the image manifest and compare it against the stored/active
security counter) as an optional part of the image validation process
to prevent the restoration of older, potentially vulnerable images.
- This feature can be enabled with the MCUBOOT_HW_ROLLBACK_PROT option.
- Add security counter interface to MCUBoot. If HW rollback protection
is enabled then the platform must provide a mechanism to store and
read the security counter value in a robust and secure way.
Change-Id: Iee4961c1da5275a98ef17982a65b361370d2a178
Signed-off-by: David Vincze <david.vincze@arm.com>
Depends on 'MCUBOOT_OVERWRITE_ONLY' option since swap info is not protected
by signature
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Start with some documentation on ECDSA signatures, and the problems with
the current padding approach. Present a plan to support correctly
formatted ECDSA signatures, and how to handle the transition both in the
C code, as well as the tooling that signs images.
Signed-off-by: David Brown <david.brown@linaro.org>
When pages are built from the markdown sources, the html anchors for
titles are automatically added, but no links are inserted in the pages.
This makes it harder to send URLs to sections; one has to browse the
page source to get the correct link. This fixes the issue by adding
links directly to the generated pages.
Signed-off-by: Fabio Utzig <utzig@apache.org>
URL anchors are already generated automatically by the GH markdown
processor, but they are not visible. This adds the proper links to the
page.
Signed-off-by: Fabio Utzig <utzig@apache.org>
Philip Colmer