Skip to content

Fix STM32U5 fallback erase and rollback handling#815

Merged
dgarske merged 3 commits into
wolfSSL:masterfrom
danielinux:stm32u5-flash-lock-fix
Jul 2, 2026
Merged

Fix STM32U5 fallback erase and rollback handling#815
dgarske merged 3 commits into
wolfSSL:masterfrom
danielinux:stm32u5-flash-lock-fix

Conversation

@danielinux

Copy link
Copy Markdown
Member

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

Copilot AI review requested due to automatic review settings July 2, 2026 16:25

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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, and max_v on 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 around hal_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.

Comment thread src/libwolfboot.c
@danielinux danielinux force-pushed the stm32u5-flash-lock-fix branch from 31615df to 020d126 Compare July 2, 2026 16:58

@dgarske dgarske left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 flashsrc/libwolfboot.c:801-805
  • [Low] [review-security] hwswap anti-rollback boot_panic() denial branch is now unreachable and no longer covered by any testsrc/update_flash_hwswap.c:56-64
  • [Low] [review] Script name sim-dualbank-rollback-denied.sh no longer matches its behaviortools/scripts/sim-dualbank-rollback-denied.sh:1-66
  • [Low] [review] Convoluted if(locked)/if(!locked) guards around partition_magic_writetools/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

Comment thread src/libwolfboot.c
Comment thread src/update_flash_hwswap.c
Comment thread tools/scripts/sim-dualbank-rollback-denied.sh
Comment thread tools/unit-tests/unit-nvm.c Outdated
- 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
@danielinux danielinux requested a review from dgarske July 2, 2026 17:47
@dgarske dgarske merged commit 39f079f into wolfSSL:master Jul 2, 2026
389 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants