Fix STM32U5 fallback erase and rollback handling#815
Conversation
There was a problem hiding this comment.
Pull request overview
This PR targets two boot-fallback failure modes affecting the STM32U5 dual-bank “hwswap” path: (1) ensuring a failing internal-flash partition erase actually occurs when flash is locked, and (2) preventing stale version state from triggering a false anti-rollback panic after an erase-and-retry fallback.
Changes:
- Recompute
boot_v,update_v, andmax_von each hwswap retry loop iteration to avoid stale anti-rollback comparisons after erasing a bad image. - Update
wolfBoot_erase_partition()to unlock and re-lock internal flash aroundhal_flash_erase().
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/update_flash_hwswap.c |
Moves version computations into the retry loop so fallback after erase doesn’t use stale max_v. |
src/libwolfboot.c |
Adds internal-flash unlock/lock around partition erase operations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
31615df to
020d126
Compare
dgarske
left a comment
There was a problem hiding this comment.
Skoll Multi-Scan Review
Modes: review + review-securityOverall recommendation: COMMENT
Findings: 5 total — 5 posted, 0 skipped
4 finding(s) posted as inline comments (see file-level comments below)
1 finding(s) not tied to a diff line (full detail below)
Posted findings
- [Low] [review-security] wolfBoot_erase_partition() now leaves internal flash LOCKED on return; peripheral in-tree caller writes to locked flash —
src/libwolfboot.c:801-805 - [Low] [review-security] hwswap anti-rollback boot_panic() denial branch is now unreachable and no longer covered by any test —
src/update_flash_hwswap.c:56-64 - [Low] [review] Script name sim-dualbank-rollback-denied.sh no longer matches its behavior —
tools/scripts/sim-dualbank-rollback-denied.sh:1-66 - [Low] [review] Convoluted if(locked)/if(!locked) guards around partition_magic_write —
tools/unit-tests/unit-nvm.c:318-323
Findings not tied to a diff line
Sibling update_ram.c retains the stale max_v pattern this PR fixes in hwswap
File: src/update_ram.c:253-290
Function: wolfBoot_start (update_ram)
Severity: Low
This finding is NOT introduced by the PR and is outside the changed file set; it is raised only for consistency because it directly parallels the hwswap fix. update_flash_hwswap.c now recomputes boot_v/update_v/max_v inside the boot loop so that anti-rollback re-evaluates after a failing image is invalidated. src/update_ram.c still computes boot_v/update_v/max_v once before the loop (lines 253-257) and reuses them in the anti-rollback guard (lines 282-290). The mechanics differ (the update_ram fallback at backup_on_failure flips active without erasing, so versions persist), so the exact stale-erase trigger does not occur; however the same design intent - allowing fallback to a lower valid image when a higher image is corrupt - is not reflected here, and a higher-but-corrupt image would still drive max_v high enough to panic when falling back to the lower valid partition. Worth confirming whether the analogous behavior is intended for the RAM updater.
Recommendation: Confirm intended behavior for the RAM updater; apply the same recompute if consistency is desired. Out of scope for this PR - track separately.
Referenced code: src/update_ram.c:253-262 (10 lines)
Review generated by Skoll
- Document wolfBoot_erase_partition() lock postcondition in doxygen - Comment the hwswap anti-rollback guard as defense-in-depth - Clarify sim-dualbank-rollback-denied.sh purpose via header comment - Simplify lock guards in unit-nvm partition_magic_write test
Fixes two bugs in the STM32U5 dual-bank fallback path.
When wolfBoot invalidates a failing internal-flash partition, wolfBoot_erase_partition() now unlocks and re-locks internal flash itself. That makes the helper safe for existing callers, including the hwswap
fallback path and wolfBoot_dualboot_candidate(), and fixes the STM32U5 case where erase operations could silently do nothing while flash was still locked.
The hwswap boot loop in update_flash_hwswap.c now recomputes boot_v, update_v, and max_v on each retry. That prevents a corrupted higher-version image from leaving behind a stale max_v after erase and
triggering a false anti-rollback panic when falling back to the remaining valid image.
zd22096