AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 28 Bitcoin

refactor(core): dma2d_wait() busy wait removal

Public commit record

What the developer wrote

Authored by bleska

80/100 · Strong
refactor(core): dma2d_wait() busy wait removal

dma_transfer_in_progress boolean variable has been added for tracking of dma2d current state (transferring/idle). The variable is set after dma2d successful transfer start and cleared inside the dma2d_wait() function after the dma2d transfer has finished.

dma2d_wait() function has been refactored from HAL based busy waiting variant to a priodical polling of dma2d status flags (TC, TE, CE) and sleep/wake concept using the dma2d to wake MCU when such event occurs.

WFE (Wait For Event) instruction is used for MCU sleep entry. The "SCB.SCR.SEVONPEND" bit is used to enable MCU wake-up with NVIC disabled IRQs.

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how the Trezor hardware wallet's graphics chip (DMA2D) waits for image-copying operations to finish. Previously the CPU burned power in a tight loop; now it puts the CPU to sleep and wakes it when the transfer completes. The change introduces new state tracking and error handling, but it also manipulates low-level CPU sleep/interrupt settings and manually clears locks and flags. There is no claim in the commit that this fixes a security bug, and no external advisory is provided. The main concern is whether the new wait logic could, in rare timing situations, leave the driver in an inconsistent state that affects screen rendering or stability, rather than a direct exploit path.

Recommended action

Treat as a non-security refactor unless additional context emerges. Review the WFE/SEVONPEND interaction for race conditions, verify that __HAL_UNLOCK cannot release a lock owned by another context, and ensure the timeout and abort path cannot deadlock or corrupt subsequent DMA2D operations. Regression testing should cover rapid init/deinit and concurrent rendering paths.

Security signals we found

01

Refactor of low-level DMA2D synchronization from busy-wait to WFE/SEVONPEND sleep-wake

02

Manual __HAL_UNLOCK and NVIC_ClearPendingIRQ added to recover HAL state

03

New dma_transfer_in_progress flag used to gate wait logic

04

Timeout-based fallback (10 ms) with abort-and-reset on error/timeout

05

No changelog entry and no security framing by vendor

Risk score

Why this scored 28/100

Our methodology →
Potential impact 5/30
Exploitability 4/25
Stealth signal 6/15
Affected reach 5/15
Confidence 5/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.