We recently encountered an issue with incompatible image partitions being pushed to in-field devices causing soft bricking. refer to this ticket for more informationMCUBOOT Application preventing further dfu.
Problem statement: current implementation DFU could potentially flash a device with a different partition or incompatible configurations that prevents future updates to the device or may cause damage, respectively.
Proposal: implement features that do the following: check image partition, check image/hardware compatibility. this will be at the start of the dfu process before any image data is accepted.
things to consider: where will be compatibility flags be stored? (mcumgr/nrf compiler vs custom header)
how is partition exposed (in binary? compile time only? do we need to be aware of our partitions and append or is that baked into existing structure)
verification criteria:
- Image with VALID partition and VALID compatibility flags -> Accepted, flashes and runs without error (Good image)
- Image with INVALID partition and VALID compatibility flags -> Rejected and dfu does not run (Bad image)
- Image with VALID partition and INVALID compatibility flags -> Rejected and dfu does not run (Bad image)
- Image with INVALID partition and INVALID compatibility flags -> Rejected and dfu does not run (Bad image)
Our goal is to implement guard rails that prevent incompatible images from either a) being accepted before any image data is transferred or b) prevent image from running in primary slot.
Current understanding is that there are configurations for hardware compatibility flags, factory data partitions, and application-level business logic.
Looking to gain insight on best practices other teams have implemented to prevent faulty code from breaking devices in the event that it slips past quality control.
For partition checks specifically, is there a configuration that can be enabled that allows mcuboot to check the partition of an incoming image, reject if incompatible?