Use the bootutil_log.h APIs to log the boot source chosen by the
loader, as well as the image trailer state that led it to its
conclusion.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Now that mcuboot has its own logging subsystem, use that instead.
Note that this changes the domain from "[BOOTLOADER]" to "[MCUBOOT]".
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This patch adds platform-independent logging to bootutil.
When bootutil is compiled as part of an application, the
application environment can provide logging hooks using this
file. Initially, hooks for Zephyr are provided. When built for
simulation or unit testing, the logging macros produce no
code (the ignore.h used by mynewt is used to avoid unused
variable warnings in this case).
Before including this file, users may define BOOT_LOG_LEVEL. If
they do, it must be one of BOOT_LOG_LEVEL_OFF,
BOOT_LOG_LEVEL_ERROR, ..., BOOT_LOG_LEVEL_DEBUG. This determines
the log level for the current translation unit. If they do not, a
default log level is determined in a target-specific way.
After including bootutil_log.h, the macros BOOT_LOG_ERR(),
BOOT_LOG_WRN(), etc. may be used to log messages. These take
printf-like arguments.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Because of branch, and https server configuration issues, the plain 'go
get' instructions to build imgtool don't work. Add a note to the README
file for imgtool and give some instructions on how to manually clone the
necessary git repositories.
Currently, the flash map is a single entry sized to fit the
FLASH_AREA_IMAGE_0_SIZE. This works for HW where
FLASH_AREA_IMAGE_SCRATCH_SIZE is the same or larger than
FLASH_AREA_IMAGE_0_SIZE.
However, if FLASH_AREA_IMAGE_SCRATCH_SIZE is smaller than
FLASH_AREA_IMAGE_0_SIZE, we need to generate enough write blocks in the
flash_map so that each will fit in FLASH_AREA_IMAGE_SCRATCH_SIZE.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
In Zephyr there is a flash HAL function: flash_write_protection_set()
which for many SoCs is a stubbed function with no functionality,
but for others performs the unlock / lock procedures required before
writing to flash.
We need to add this function to our flash_area_write() wrapper
to support the hardware that requires it.
This fixes mcuboot flash writing for the nRF5x SoCs.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Zephyr now supports moving the vector table for Corext M* targets.
Let's remove this code from mcuboot as this has been changed
upstream and breaks mcuboot build.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Make it clear in the top-level Makefile how to configure mcuboot for
Zephyr for a particular signing algorithm. Currently supported, are the
RSA signatures, and ECDSA with the P-256 curve. These configuration
lines will select the code built in the bootloader, as well as which
public key gets included with the image.
This also adds a demo public key for the P-256 signatures.
Instead of just checking the upgrade image signature, check the
signature on each boot. This helps to prevent rogue images being flash
by a means other than the upgrade process.
This feature is controlled by whether BOOTUTIL_VALIDATE_SLOT0 is
defined.
The ECDSA signature is written as two DER-encoded INTEGERS. Although
the values are always 256 bits, the encoding ends up being variable
length, because the encoding is signed, and therefore needs an extra
zero byte to keep the number positive. This means that the length can
vary by up to two bytes.
The 'newt' tool handles this for signature by allowing space for the
largest encoding, and padding with one or two zeros. However, the
bootutil image check code insists that the length is exact, resulting in
a decoding error on about 3/4 signatures.
Fix this by only verifying that we have at least enough payload to hold
the signature. There are later checks that will fail if the integers
themselves are too large.
The --key-type (-t) parameter to keygen allows (requires) the user to
specify the type of key to generate. This now supports "ecdsa-p224" and
"ecdsa-256". Note that the curve must match the one coded into the
bootloader.
The imgtool is a simple image signing tool based on the libraries in the
`newt` tool, but appropriate for images that live outside of a Mynewt
project.
This initial version is able to generate, extract public keys from, and
sign ECDSA P-256 keys. The signing tool is also able to add an image
trailer to mark this image for upgrade.
Merge remote-tracking branch 'd3zd3z/big-align'
* d3zd3z/big-align:
bootutil: Fix issue with align > 1
sim: Set version numbers in images
sim: Add some debug code to dump images
sim: Write image_ok properly
sim: pad images to alignment
sim: Make misaligned writes panic
sim: Be consistent about flash alignment
sim: Verify write alignment
sim: Add the K64fBig target
k64f: change flash device name
scripts: Allow image version number
scripts: Remove .pyc file from repo
Add some simple scripts for signing/flashing
Some flash devices not only require writes to occur on an `align` byte
boundary, but also require that the writes be done in chunks of this
size as well. Enhance the sections that write status bytes to write
more than a single status byte.
To make the images easier to identify during analysis, set the version
number. The major number tries to be set to the slot number, and the
build number is the byte offset.
Add an --image-version argument to zep2newt.py to allow the major
version number to be set. This helps make testing easier by having
differing version numbers.
These are some simple scripts for signing images (with an example with a
hardcoded path), a fixed root key that matches the one checked into the
code, and a few scripts to use the Segger debugger to flash the images.
Merge remote-tracking branch 'rsalveti/zephyr-updates'
* rsalveti/zephyr-updates:
zephyr: use SYS_LOG instead of printk
image_rsa: include missing string.h
boot/zephyr/prj.conf: disable bluetooth support by default
boot/zephyr/prj.conf: remove SOC_FLASH_STM32F4, make it generic
zephyr: targets: add support for 96b_nitrogen
zephyr: restructure the build process to use board config files
Bluetooth is enabled by default with some boards, so just make sure that
it gets disabled here to avoid having a large bootloader firmware.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Make it generic and let the SoC itself handle the FLASH driver support
as part of the Zephyr build system.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Move the board specific configurations into its own header file, which
can now be created per board, once it gets tested and validated by the
bootloader.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
This reverts commit 920fc16b89.
The boot loader records its current state in the form of a pair of image
trailers, each located at the end of the corresponding image slot. If
an image is so big that it extends into the trailer space of a slot, the
boot loader would read the end of the image and interpet it as the start
of a trailer. The fix was to determine the size of each image upfront
by reading their headers, and only attempt to read an image's trailer if
the image is small enough that it doesn't extend into the trailer space.
If an image is too big to allow for a trailer, the boot loader fails
over to its "rescue mode": just boot into whatever is in slot 0.
The problem arises when the boot loader reads the image headers. There
are certain points during a swap when an image header is not in the
expected location. That is, if the device reboots at the wrong time
during an image swap, the boot loader will fail to read the image
headers when it comes up.
The image sectors are swapped in reverse order. When a swap is
performed, the final sectors of each slot are swapped first, and the
first sectors (containing the image headers) get swapped last. During
the final swap operation, there are two points at which the image
headers are not in the expected place:
1. slot 1 erased; header 1 in scratch area.
2. slot 0 erased; header 0 in scratch area.
In each case, the image header is not actually missing. Rather, the
boot loader is just looking in the wrong place. It should be looking in
the scratch area, not the start of the image slot.
The fix is to revert the original commit. Now, the boot loader won't
fail when an image header read fails. It is the user's responsibility
to ensure an image isn't too big.
Marti Bolivar