Runtime CRC-32 over MCUboot Image Data in a Dual-Slot Swap Configuration

[TK5090]

Description

We are using MCUboot in a dual-slot swap configuration in a safety-related
application and need to perform a runtime ROM integrity check.

The CRC-32 is intended as an additional runtime integrity mechanism. It is not
intended to replace MCUboot signature verification.

We are evaluating two approaches.

1. CRC-32 over application payload only

In the first approach, we calculate a CRC-32 over the application payload
(zephyr.bin), excluding the MCUboot image header.

The CRC-32 is calculated before signing, stored in the protected TLV area, and
the resulting image is signed during the build process using imgtool, with the signing operation performed by our HSM..

This approach works as expected. However, the CRC is then part of the protected
and signed MCUboot image metadata.

2. CRC-32 over the complete MCUboot image, stored outside the signed data

For our safety requirements, we would prefer a CRC-32 over the complete
MCUboot image representation, including the image header, payload, and MCUboot
TLVs.

Our intended workflow is:

1. Build the application image.
2. Sign the image Imgtool and by our HSM.
3. Calculate a CRC-32 over the resulting signed MCUboot image.
4. Store the CRC-32 in an additional 4-byte field.
5. At runtime, calculate the CRC-32 over the same byte range, excluding the
   stored CRC-32 field itself, and compare it with the stored value.

The CRC-32 field must remain outside the signed data. It must nevertheless be
preserved when MCUboot swaps Slot 1 into Slot 0.

Problem

We tried reserving four additional bytes in the slot layout for the CRC-32.

• If the four bytes are included in the reserved slot/image space, MCUbootrejects the image because the image no longer fits into the usable
  slot area.
• If the four bytes are not included in the layout, the CRC-32 data is not
  copied from Slot 1 to Slot 0 during a swap.

We also understand that the end of an MCUboot slot contains the MCUboot image
trailer and swap status. Therefore, placing application-owned immutable data at
the physical end of the slot may conflict with MCUboot trailer handling.

Questions

What is the intended MCUboot mechanism for storing additional application
metadata that meets all of the following requirements?

• It is generated after the signing step.
• It is not included in the signed data.
• It is preserved when an image is swapped from Slot 1 to Slot 0.
• It does not conflict with the MCUboot image trailer or swap status.
• Its storage requirements are accounted for correctly when checking whether an
  image fits in a slot.

More specifically:

1. Is an unprotected vendor-specific TLV the intended mechanism for this use
   case?
2. If so, is there a supported imgtool or Zephyr build configuration for
   adding such a TLV after signing?
3. Does MCUboot copy unprotected TLVs during all supported swap modes?
4. If an additional non-TLV field is required, is there a supported way to
   reserve space for it without reducing the maximum usable signed image size?
5. Is modifying the MCUboot image format or swap implementation the only valid
   approach if the CRC must cover a byte range different from the MCUboot image
   and TLV layout?

Environment

• MCUboot version: [v.2.1.0]
• Zephyr version: [v4.1.0-10-ga34e9a85fcbb]
• Target MCU / board: [STM32H533RE]
• Swap mode: [MOVE]
• Exact error message or boot log:
  if (last_idx >= first_trailer_idx) {
  BOOT_LOG_WRN("Not enough free space to run swap upgrade");
  BOOT_LOG_WRN("required %d bytes but only %d are available",
  (last_idx + 1) * sector_sz,
  first_trailer_idx * sector_sz);
  bs->swap_type = BOOT_SWAP_TYPE_NONE;
  return;
  }

Any guidance on the intended MCUboot mechanism or the correct configuration for this use case would be greatly appreciated. Thank you in advance for your time and support.

[jmrplens]

Not with MCUboot as it is: since 2.1.0 it rejects an image whose unprotected TLV area carries a type that is not on its allow list, and nothing outside the TLV area is guaranteed to travel with the image. The integrity check you are after can be done without storing anything after signing, though. Taking your questions in order:

1. Unprotected vendor TLV: no. The 2.1.0 release notes say "Enforce that TLV entries that should be protected are". bootutil_img_validate() walks the unprotected area and fails the image on any type that is not in allowed_unprot_tlvs (hashes, key hash or public key, signatures, encryption keys), unless MCUboot is built with ALLOW_ROGUE_TLVS (a compile definition at your version; CONFIG_MCUBOOT_USE_TLV_ALLOW_LIST=n from MCUboot 2.3.0). I checked it in MCUboot's simulator with swap-move, both at v2.1.0 and at 346f7374, the MCUboot revision Zephyr v4.1.0 pins: the same upgrade with a 4-byte vendor TLV appended to the unprotected area fails ("Unable to perform basic upgrade"), and passes without that TLV or with ALLOW_ROGUE_TLVS defined. On the device MCUboot logs "Image in the secondary slot is not valid!" and erases that slot, and with BOOT_VALIDATE_SLOT0 the same TLV in an image flashed straight into the primary slot stops it from booting. Defining it undoes a hardening step, which is a hard thing to argue for in a safety case.
2. imgtool: no. --custom-tlv is "Custom TLV that will be placed into protected area", which is your approach 1, and no version has an option for unprotected ones. Zephyr's CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS only forwards options to that same imgtool sign.
3. Unprotected TLVs in a swap: yes, in every mode of the Zephyr port. They copy the extent from boot_read_image_size(): header, payload, protected TLVs and the unprotected TLV area, up to the length in its 0x6907 info header. Overwrite-only copies that many bytes; swap-move moves the sectors that hold the larger of the two images. Bytes after the TLV area are not part of the image, and under swap they only come along if they happen to sit in a sector the larger image already occupies, which fits what you saw.
4. Reserving space outside the image: no. The fit check in your log counts the sectors the larger of the two images needs, plus the one swap-move shifts by, so extra bytes either count against the image or are not copied.
5. You do not need to change MCUboot, because the check can use what MCUboot already stores:
   • The unprotected area holds IMAGE_TLV_SHA256 (0x10, the default hash for every signature type in MCUboot's Zephyr port): the hash of header, payload and protected TLVs, the exact range MCUboot hashes before it checks the signature. At runtime, recompute it over that range in the primary slot and compare. That covers the header, the payload and your protected TLVs with no layout change, using SHA-256, whose chance of missing a corruption (about 2^-256) is far below CRC-32's (2^-32), though without the guaranteed Hamming distance a CRC gives if your standard asks for one. Zephyr has the primitive: flash_area_check_int_sha256() (CONFIG_FLASH_AREA_CHECK_INTEGRITY), with clen = ih_hdr_size + ih_img_size + ih_protect_tlv_size and match set to the 32 bytes of TLV 0x10. I ran that on native_sim (current Zephyr; the function is the same in v4.1.0) against an image signed with imgtool 2.1.0: it returns 0 for the intact image and -EILSEQ with one bit flipped in the header magic, the payload or a protected TLV. Treat a missing 0x6907 area or TLV 0x10 as a failure too, since a flip in the header's size fields moves the range instead.
   • It does not cover the unprotected area itself. Nothing in that area is executed or read by the application, so damage there has no effect until the next boot, when MCUboot rejects it: its CONFIG_BOOT_VALIDATE_SLOT0 (on by default) re-verifies the primary slot on every boot.
   • If the safety argument still needs one CRC-32 over the whole extent, compute it on the device instead of at build time. At boot, after MCUboot has verified the primary slot, compare the running image's TLV 0x10 with the one stored next to your CRC; if they differ, compute the CRC from the header to the end of the TLV area and store both outside the slots (a settings entry or a partition of its own). Keying it by the image hash covers a revert, a permanent upgrade that never calls boot_write_img_confirmed() and a factory-flashed image, and it survives every later swap because it never lives in the slot.

[TK5090]

We decided to calculate the CRC-32 over the application payload in zephyr.bin, starting at offset 0x400 when MCUboot is used as the bootloader. This excludes the MCUboot image header and covers only the actual application binary.

The calculated CRC-32 value is then patched into the unprotected TLV area using imgtool. The image is signed afterwards.