Earlier refactoring created a call for get_public_bytes() that was added
to the RSA class, but missed on the ECDSA class. Add this call so that
ECDSA signatures will work again.
Signed-off-by: David Brown <david.brown@linaro.org>
The keyhash should be able to have any size up to the maximum allowed
size of 32, but the assert was not allowing images created with newt to
be accepted as valid (newt currently uses only 4 bytes for keyhash).
Signed-off-by: Fabio Utzig <utzig@apache.org>
Signed-off-by: David Brown <david.brown@linaro.org>
When starting a swap upgrade, the total size of data to be swapped is
calculated only at the beginning and saved to the trailer. This avoids
having to use complicated heuristics to find the total swap size, which
might depend on data that was already moved. When resuming a swap, the
size is found in the trailer and used.
Also includes some small comment fixes and refactors.
Signed-off-by: Fabio Utzig <utzig@apache.org>
Signed-off-by: David Brown <david.brown@linaro.org>
The local variable 'size' is actually the offset of the end, and not the
size. Rename it to reflect this reality.
Signed-off-by: David Brown <david.brown@linaro.org>
Clarify the name of the TLV field to more fully describe the signature
type.
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
Since we are changing the image header format, there is no reason to
continue to support the old PKCS#1 v1.5 signatures. Remove the
definitions, and conditional complication related to this, and only
support the newer PSS signatures.
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
Since we've changed the meaning of several fields in the header, bump
the header to a new magic number. The fields that are still present are
in the same place, but all of the signature and TLV information is moved
into the TLV itself, which is still immediately after the image.
As of this commit, this defines the new image header/TLV format used for
1.0.
Based on work by Marko Kiiskila <marko@runtime.io>
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
To allow the signatures to be replaced, move the size of the TLV into a
small "info" header at the start of the TLV.
Note that this causes image swapping to lose robustness. This is fixed
by a later commit.
Based on work by Marko Kiiskila <marko@runtime.io>
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
JIRA: MCUB-65
Remove the key_id field from the image header. There are two problems
with this field. First, it is only an integer offset, and so causes an
unnecessarily tight coupling between the particular keys built into the
bootloader, and the key that is used to sign. Second, it makes the
key_id part of the image header, which is included in the signature.
This makes it impossible to later sign the image with a different
signature.
Instead of the key-id, add a TLV KEYHASH entry. This will hold the
SHA256 of the public key that the signature is against. Each signature
placed in the TLV should be preceeded by this entry to indicate the
public key used.
The signature check will check each signature, and if the KEYHASH is
known and the signature type is supported, it will be checked. As long
as at least one signature is considered valid, the image will be
considered signed. This also allows the image to be signed with
multiple signatures to support having different devices with possibly
different keys compiled into the bootloaders.
Based on work by Marko Kiiskila <marko@runtime.io>
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
Add a `--rust` flag to the getpub subcommand to output the public key in
Rust format rather than C.
Signed-off-by: David Brown <david.brown@linaro.org>
In preparation for moving the signature related values out of the main
image header and into the TLV, renumber the existing TLV values to be
grouped together better.
The SHA256 is moved into the first group, at 0x10, and the signature
values themselves are moved to start with 0x20.
This change is the first in a series of changes toward the new v1.0
image format. The intermediate results are all internally consistent
(meaning that the simulator, and the builtin imgtool.py will all work
together), but until all patches are applied, the image format is not
valid with any external tools.
Based on work by Marko Kiiskila <marko@runtime.io>.
Signed-off-by: Marko Kiiskila <marko@runtime.io>
Signed-off-by: David Brown <david.brown@linaro.org>
In order to build for a particular Zephyr board, the Device Tree
definition for it in the Zephyr tree must include the flash description.
Additionally mention that a .hex version of the image is available,
useful for those flash tools that deal with Intel Hex files.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Upstream Zephyr is making a habit of enabling subsystems on any board
that supports them. That's a potential security risk if any of those
allow interference with the running bootloader, and is currently
exceeding mcuboot's flash allowance on some STM32 targets,
e.g. 96b_carbon. Turn off I2C to restore the build for those.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Adds a new zephyr target for the nrf52_blenano2. This is the BLE
Nano 2 board created by Red Bear which contains a NRF52832 MCU.
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
The hexiwear k64 is very similar to the frdm_k64, as far as mcuboot is
concerned. The partitions are now defined in DTS in Zephyr, and this
target file just needs the device name, sector size, and alignment.
Signed-off-by: David Brown <david.brown@linaro.org>
Without the leading slash, these ignore lines will ignore these names in
any subdirectory. This was ignoring Zephyr targets files, because of
the same name.
Signed-off-by: David Brown <david.brown@linaro.org>
The current "boot states" description doesn't make sense and shouldn't
be used.
For one thing, with three possible pending states, two possible
confirmed states, and two image slots each with a combined (pending,
confirmed) state, the total number of boot states is 36, but the
document says there are "four possible states".
For another, the actual bits on flash map to the "boot states" in a
way that is carefully designed to ensure that only those 4 are the
"outcome" of a boot.
The fact that this map does not cover the entire space of what is
being presented as the "logical" states of the device is a strong
indication that the pending/confirmed state space is a bad choice, not
connected with the actual operation of the bootloader.
A state space that is better for describing how the bootloader behaves
is given the by the enumeration of "swap types" which appear under
each of the tables in the "IMAGE TRAILERS" section, as well as the
bootloader code itself.
To help fix the description of the bootloader' operation, rewrite the
"boot states" portions of the design document, deleting the
pending/confirmed "states" and replacing them with swap types.
There is still more work to do here:
- There is still an "important caveat" to describing things in
terms of swap types, which means it's not quite right.
- It's strange to say that "none" is a swap type.
- This doesn't provide a clean explanation for how mcuboot handles an
interrupted swap.
But it's another step.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The swap status field definition claims image data are swapped one
sector at a time, but that's not true: image data are actually swapped
around in increments equal to the size of the scratch area, which
can be multiple sectors in length.
Its contents are also misleading in claiming that it's a series of
single byte records, which ignores padding when min-write-size > 1.
It also assumes the reader knows how images are swapped, but that's
not explained until later on in the document.
Finally, the paragraph is in a list of "definitions" of the image
trailer's fields, but it doesn't actually define the contents; it's
just a high level description of what the field is for.
Fix all of these issues by re-working this paragraph.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The design document says that image trailers can be located in
scratch. That's not true: the contents in scratch are just a subset of
the complete image trailer.
Fix this up by making it clear that image trailers are at the end of
image areas, and sometimes some of their data is copied into and out
of scratch.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The discussion about image slots assumes that the bootloader swaps,
but that is not all it can do. Clear this up.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Distinguish between flash areas and flash area IDs. Say what the
bootloader area is, since that's not discussed anywhere else.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Copy up to date image flags from image.h. Fixes for:
- Wrong comment for IMAGE_F_ECDSA224_SHA256
- Missing definition for IMAGE_F_PKCS1_PSS_RSA2048_SHA256
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
The comment for BOOT_SWAP_TYPE_NONE says "Just boot whatever is in
slot 0". That's not correct: if configured to do so (and this the
strongly recommended configuration), mcuboot will first
cryptographically validate the contents of slot 0 before booting it.
Fix the comment to be more accurate.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Adjust alignment and add missing leading zero to
IMAGE_F_PKCS1_PSS_RSA2048_SHA256. This needed some comment changes to
keep things 80 column clean.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This is a minimal example application that works on various boards,
without target-specific definitions, device tree overlay files, etc.
It's been tested on frdm_k64f, 96b_carbon, and 96b_nitrogen.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This document describes the manual testing done on Zephyr. It uses a
bunch of git patches to make modifications to the code, where each is
then tried and then backed out.
Signed-off-by: David Brown <david.brown@linaro.org>
This flag was added to the RSA config file, but not the ECDSA file. It
is needed to configure the MPU to allow the flash device to be written
to.
Signed-off-by: David Brown <david.brown@linaro.org>
Version is stored in repository.yaml for mynewt. Otherwise, put a
single mention of it in the README.md.
Signed-off-by: David Brown <david.brown@linaro.org>
Recent Zephyr trees require this config option to be set in order to be
able to write to the flash device. Without it, targets with an MPU
enabled will abort during startup, usually before even printing a
message to the UART.
Signed-off-by: David Brown <david.brown@linaro.org>
David Brown