fix(core): fix resuming from suspend when optiga is properly paired and bootloader locked
What the developer wrote
Authored by tychovrahe
fix(core): fix resuming from suspend when optiga is properly paired and bootloader locked
[no changelog]
What changed, and why it matters
This commit changes the order in which a Trezor hardware wallet resumes internal components after waking from a low-power suspend state. Previously, secure drivers were resumed after the Optiga security chip was resumed. The fix moves secure-driver resumption before Optiga resumption. The commit title says this fixes a problem that occurs when the Optiga chip is properly paired and the bootloader is locked. Without more context, the exact security impact is unclear, but an incorrect resume order could in principle cause a secure-driver failure or leave a security-critical component in an inconsistent state during wake-up.
Treat as a routine bugfix with potential security-relevant side effects. Trezor users do not need to take immediate action. Developers should verify that the new resume ordering does not introduce race conditions or leave secure drivers uninitialized when Optiga resume depends on them. A security review of the suspend/resume state machine for the STM32U5 platform is advisable.
Security signals we found
Reordering of secure-driver and Optiga resume sequences during suspend wake-up
Reference to bootloader-locked and Optiga-paired configuration in commit title
Change limited to STM32U5 low-power suspend I/O path
No changelog entry supplied
Evidence from the diff
In core/embed/sys/suspend/stm32u5/suspend_io.c, the resume_drivers() function is reordered. The call to resume_secure_drivers() is moved above the USE_OPTIGA/optiga_resume() block, rather than below it. The change is small (3 insertions, 2 deletions) and only affects the STM32U5 suspend/resume path. The commit message frames this as a fix for resuming from suspend when the Optiga is properly paired and the bootloader is locked. The diff itself does not show any crash, exploit, or vulnerability mechanism; it only shows a sequencing change.
Changed components
core/embed/sys/suspend/stm32u5/suspend_io.cSTM32U5 suspend/resume driver sequenceOptiga secure element resume pathsecure drivers resume pathInspect captured patch +3 / −2
diff --git a/core/embed/sys/suspend/stm32u5/suspend_io.c b/core/embed/sys/suspend/stm32u5/suspend_io.c
index ff0f1144..77d7243c 100644
--- a/core/embed/sys/suspend/stm32u5/suspend_io.c
+++ b/core/embed/sys/suspend/stm32u5/suspend_io.c
@@ -167,12 +167,13 @@ void resume_drivers(const power_save_wakeup_params_t *wakeup_params) {
#ifdef USE_BLE
ble_resume(&wakeup_params->ble);
#endif
+
+ resume_secure_drivers();
+
#ifdef USE_OPTIGA
// Optiga kernel part of resume routine
optiga_resume();
#endif
-
- resume_secure_drivers();
}
#endif // KERNEL_MODE
Why this scored 41/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.