boot: add delta DFU support

[hlord2000]

Summary

Adds overwrite-only delta DFU support.

A signed delta image in the secondary slot can patch the current primary image in place. MCUboot checks that the primary image matches the expected base hash, applies the delta records, and validates the reconstructed target image.

Changes

• Add imgtool support for generating signed delta images with --delta-base and --delta-block-size.
• Add optional reversible deltas with --delta-revertible.
• Add bootutil support for validating and applying delta images.
• Add optional restore support for unconfirmed test delta updates.
• Add Zephyr Kconfig options and documentation.

Testing

• uv run pytest scripts/tests/test_delta.py

[d3zd3z]

So a few high level things:

• First to be clear: this is a non-robust upgrade, much worse than overwrite only. Whereas overwrite only will effectively restart the operation, this doesn't appear to be recoverable if power is lost, effectively bricking the device. Correct me if my understand is not right, but that isn't really a mode we want to have in MCUboot.
• Second, it isn't tested (which would point out that it doesn't work with power loss).

So, in order to get this through, it is going to need to be added to the simulator for testing. And, more importantly the robustness needs to be addressed. There either needs to be an argument for a use case where bricking a device on an upgrade interruption is acceptable, or the code needs to be made robust (it needs to be able to recover, and continue the upgrade when interrupted at any point.

[hlord2000]

So a few high level things:

• First to be clear: this is a non-robust upgrade, much worse than overwrite only. Whereas overwrite only will effectively restart the operation, this doesn't appear to be recoverable if power is lost, effectively bricking the device. Correct me if my understand is not right, but that isn't really a mode we want to have in MCUboot.
• Second, it isn't tested (which would point out that it doesn't work with power loss).

So, in order to get this through, it is going to need to be added to the simulator for testing. And, more importantly the robustness needs to be addressed. There either needs to be an argument for a use case where bricking a device on an upgrade interruption is acceptable, or the code needs to be made robust (it needs to be able to recover, and continue the upgrade when interrupted at any point.

Thanks for the feedback!

On your first point: yes, there is a non-robust upgrade path. This is what I started with, just overwriting the existing application w/o maintaining a diff of delta->current firmware. Gated behind "MCUBOOT_DELTA_DFU_RESTORE" is a flow where this diff is generated before anything is overwritten. I'll remove the non-robust upgrade path, that's fine as this still represents significant NVM savings for mature applications.

I'll work on getting this working w/ the simulator.

[d3zd3z]

This looks good, thank you for the work. Just a few questions:

• First, this will need to be rebased to be able to merge.
• Does the security counter properly update when the reversible delta is confirmed.
• Please update the description, which still describes --delta-revertible as optional, and doesn't mention the robustness rework.
• The per-record bounds are validate in a pass separate from where records are re-read and applied. A flash change between the two passes could smuggle an out-of-range offset/size. This isn't exploitable remotely, and I think this requires physically changing the flash between verified flash, so probably isn't covered by our threat model, but something to keep in mind.
• Please update docs/design.md to describe the new flag and TLFv.
• It might be worth mentioning in docs/delta_dfu.md that since each changed region costs 2x bytes, a delta that touches scattered regions could exceed a plain overwrite in size.