Repository navigation
Guard the STM32H7S GFXMMU window with an MPU region while the D-cache is on - #985
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
There are no active review issues for the change protecting the GFXMMU window from speculative reads during boot.
No open issues 🎉
What changed in this PR
Hardens STM32H7S boot-time operation against speculative reads into the clock-disabled GFXMMU window, which can stall the bus when the D-cache is enabled.
Changes:
- Adds MPU register definitions and a no-access guard for the 16 MB GFXMMU window.
- Enables the guard before the D-cache and removes it after disabling caches during application handoff.
- Documents the hazard and the protection applications need when enabling their own D-cache.
| File | Description |
|---|---|
| hal/stm32h7s.h | Defines MPU registers, region attributes, and the GFXMMU window base. |
| hal/stm32h7s.c | Installs the MPU guard during initialization and removes it before application handoff. |
| docs/Targets.md | Explains the GFXMMU hazard and application-side MPU requirements. |
Review effort: Balanced
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #985
Scan targets checked: wolfboot-src, wolfboot-bugs
Not reviewed (no scan target covers them): docs/Targets.md, hal/stm32h7s.h
Coverage: 1 of 1 in-scope changed file(s) opened by the reviewer
Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)
This review was generated automatically by Fenrir. Reported findings require changes before merge.
Review tier: Max
e0ca607 to
e00f150
Compare
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #985
Scan targets checked: wolfboot-src, wolfboot-bugs
Not reviewed (no scan target covers them): docs/Targets.md, hal/stm32h7s.h
Coverage: 1 of 1 in-scope changed file(s) opened by the reviewer
Fenrir result: Approved ✅
No new issues found in the changed files.
Advisory only — this automated result does not count as a GitHub approval.
Review tier: Lite
Fenrir's latest completed scan found no issues; clearing the prior automated change request.
Description
Hardening for the STM32H7S target, found while root-causing wolfSSL/wolfip#192 on a NUCLEO-H7S3L8.
A speculative read into the GFXMMU window stalls the bus
On STM32H7R/S,
0x25000000-0x25FFFFFFholds the GFXMMU virtual buffers. With the GFXMMU clock off, the reset state, a read there never completes: no bus error comes back, the core stalls, and the debugger can no longer halt it. The window is Normal memory in the default memory map, and a Cortex-M7 with the D-cache enabled may read Normal memory speculatively, so nothing has to read it on purpose.hal_init()enables the D-cache and the target builds withNO_MPU=1, which leaves the window open while the image is hashed and verified.hal_init()now programs one MPU region marking the window no-access before it enables the D-cache, andhal_prepare_boot()clears it again together with the caches. The region is one thatmpu_init()insrc/boot_arm.cleaves free. WithNO_MPU=1, the target's default, the HAL also enables the MPU around it and disables it before the jump, so the application still starts from the reset state; withNO_MPU=0wolfBoot's own map is left as it is.Testing
NUCLEO-H7S3L8. An application running from the XSPI NOR with the D-cache on freezes within a minute under TLS load, and stops freezing with this one region added; a single debugger read of
0x25000000on an idle board freezes it. In wolfBoot itself the freeze was not observed: stock and patched wolfBoot each booted a 3.8 MB signed image 60 times out of 60. With the change, boot, signature verification and the--test-updateswap to version 2 pass in both theNO_MPU=1andNO_MPU=0builds.