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

fix(core): get rid of confidential global vars

Public commit record

What the developer wrote

Authored by cepetr

57/100 · Thin
fix(core): get rid of confidential global vars

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit removes a special firmware memory section called ".confidential" that was meant to keep sensitive data (like cryptographic keys and seed-derived values) separate from ordinary memory. Previously, variables marked with a CONFIDENTIAL attribute were placed in this dedicated RAM region and copied from flash at startup. The patch deletes that whole mechanism across all Trezor models and instead marks sensitive local variables with a new LOCAL_CONFIDENTIAL macro. On the legacy build this still maps to the old behavior, but on the modern STM32 builds it effectively becomes a no-op, meaning those sensitive buffers now live in normal RAM/data sections. The change is presented as a cleanup, but it reduces a defense-in-depth isolation feature and could make it easier for a successful attacker to locate or extract secret material in memory.

Recommended action

Treat this as a defense-in-depth regression rather than an active vulnerability. Review whether the .confidential section was relied upon by downstream hardening (e.g., TrustZone MPU configuration, firmware-update integrity checks, or side-channel countermeasures). If so, reintroduce equivalent isolation, for example by mapping LOCAL_CONFIDENTIAL to a protected MPU region or by restoring the section for devices that support it. Verify that removing the section does not change the runtime layout in a way that breaks stack/heap boundaries or exposes secrets through uninitialized RAM. Add a changelog/security note explaining the rationale and compensating controls.

Security signals we found

01

Removal of dedicated .confidential RAM/flash section used for secret buffers

02

Deletion of startup copy routine that initialized confidential RAM from flash

03

Crypto and storage sensitive buffers moved from section-isolated globals to normal data/stack semantics

04

Build-system change makes CONFIDENTIAL a no-op on STM32F4/STM32U5/Unix builds

05

Legacy build retains CONFIDENTIAL/LOCAL_CONFIDENTIAL mapping, creating a behavior split

06

Bootloader global variables stripped of CONFIDENTIAL attribute

07

No changelog entry despite security-relevant memory-layout change

Risk score

Why this scored 63/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 14/15
Confidence 7/10
Evidence quality 4/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.