Add a simple function to query the bootloader for capabilities.
Ultimately, this API should be available to the running app, but the
simulator can use this to determine what to test.
Instead of a separate invocation of printf to print the trailing
newline, use some modern cpp trickery to expand the format string
explicitly. The ## will remove the preceding comma of the argument list
if empty.
Add logging support for when running in the simulator. Log messages are
still based on compile-time determinations, and log using printf.
Based on a patch from Marti Bolivar <marti.bolivar@linaro.org>.
When building with ECDSA P-256 as the signature algorithm, we are still
bringing in SHA256 and some ASN.1 code from mbed TLS. Fix part of this
by wrapping the hash functions with general routines (inline functions)
allowing to select between mbed TLS and Tinycrypt for the
implementation.
Update the Zephyr config files so that the Tinycrypt version is used
when building the ECDSA P-256 signing variant.
There are some problems with how mbed TLS is configured in Zephyr.
First, include the makefile stub in the Makefile that uses these
defines. This makes sure the right definitions get made so that our
custom config gets used for all compiled files, rather than a mixed set.
Also, fix up the wrappers on the custom configs so that each is
different, making it easier to detect if multiple configs are being
included.
Lastly, only include the right header in the image validation. The mbed
TLS includes don't seem to want to allow both RSA and ECDSA to be used
(due to the key size), and including the wrong header results in a
compilation error.
Previously, the return of boot_swap_sectors() was discarded. If a flash
operation failed, this information was lost.
Now, boot_swap_sectors() returns void. Rather than returning a result,
success is asserted for all flash operations during function execution
(boot_copy_sector() and boot_erase_sector()).
commit d930ec69c8
Author: David Brown <david.brown@linaro.org>
Date: Wed Dec 14 07:59:48 2016 -0700
Validate slot zero before booting
adds a feature to validate slot 0 before booting it. However, there
is an error in the logic, and if the magic number is written to an
invalid value, but not all 0xFF, it will consider any image to be
valid.
Fix this logic so that slot zero is always validated.
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>
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>
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.
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.
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.
The previous commit for this ticket left the code in a working state.
However, it was not possible for image management to distinguish between
the test and permanent states.
Now, these two states are indicated by the addition of a new swap type:
BOOT_SWAP_TYPE_PERMANENT.
Currently, to permanently run the alternate image, the boot loader
requires the following sequence:
1. image test <slot-01-hash>
2. reboot
3. image confirm
The new feature is to remove the need for the third step. The user
should be able to permanently switch images with this sequence:
1. image confirm <slot-01-hash>
2. reboot
David Brown