boot: add delta DFU support - #2743
Conversation
d3zd3z
left a comment
d3zd3z
left a comment
There was a problem hiding this comment.
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. |
10138cf to
53ff542
Compare
d3zd3z
left a comment
d3zd3z
left a comment
There was a problem hiding this comment.
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-revertibleas 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.mdto describe the new flag and TLFv. - It might be worth mentioning in
docs/delta_dfu.mdthat since each changed region costs 2x bytes, a delta that touches scattered regions could exceed a plain overwrite in size.
0e64f5e to
bba518b
Compare
d3zd3z
left a comment
d3zd3z
left a comment
There was a problem hiding this comment.
From my perspective, the only thing remaining is to update the description of the pr to match what the change now does.
Just updated |
| #define IMAGE_TLV_DELTA_BASE_SHA 0x76 /* SHA of image the delta applies to */ | ||
| #define IMAGE_TLV_DELTA_TARGET_SHA 0x77 /* SHA of image produced by the delta */ |
There was a problem hiding this comment.
we already have TLVs for output and input SHA, see decomp, I dont think we should add more when we can just reuse those (they can be renamed)
| uint8_t new_data[size]; | ||
| uint8_t old_data[size]; |
Add protocol-v1 signed reversible delta images for overwrite-only upgrades. Store old and new bytes for each changed region, reserve recovery sectors in both slots, and resume forward apply or restore safely after power loss. Revalidate record bounds while applying them, validate reconstructed images before committing metadata, and defer rollback-counter advancement for test updates until confirmation. Extend imgtool, Zephyr integration, documentation, and simulator coverage for the complete flow. Assisted-by: GPT-5.5 Signed-off-by: hlord2000 <kellyhlord@gmail.com>
Run unsigned, ECDSA-signed, and hardware rollback-protected delta DFU configurations in the simulator matrix. Assisted-by: GPT-5.5 Signed-off-by: hlord2000 <kellyhlord@gmail.com>
bba518b to
94bd730
Compare
3 participants
Summary
Adds overwrite-only delta DFU support.
A signed reversible delta image in the secondary slot can patch the current primary image. MCUboot verifies the expected base, recovers interrupted updates using the stored old bytes, and validates the reconstructed target. Unconfirmed test updates can be reverted.
Changes
imgtoolsupport with--delta-baseand--delta-block-size.bootutilsupport for validation, application, and reset-safe recovery.Testing
uv run pytest scripts/tests/test_delta.py