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

orientation-screen: Migrate to rust

Public commit record

What the developer wrote

Authored by Niklas Dusenlund

60/100 · Adequate
orientation-screen: Migrate to rust

create an async friendly hardware supported delayin C and wrap it in
rust using Future.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
The short version

What changed, and why it matters

This commit rewrites the BitBox02's startup orientation screen from C to Rust and introduces a new shared delay/timer subsystem. It is a refactoring change: the device still asks the user to pick screen orientation at boot, then waits 1.3 seconds before switching to the lock screen and enabling USB/Bluetooth. The rewrite changes how internal timers and product-version strings are handled, but it does not add or remove security features. There is no vendor statement that this fixes a security bug.

Recommended action

Treat as a normal refactoring commit. Review the new delay subsystem for race conditions and slot exhaustion, verify the Rust/C callback lifetime contract in `orientation_arrows`, and ensure `delay_cancel` is always called (including on task abort) to avoid leaking timer slots. No immediate security patch is indicated.

Security signals we found

01

New timer/delay subsystem with fixed 10-slot pool; `delay_init_ms` aborts on exhaustion

02

Callback double-invocation mitigation in `orientation_arrows.c` (`done_callback` nulled after use)

03

Product/version string generation moved to `platform_init.c` and shared between bootloader and firmware

04

Removal of `volatile` qualifier on BLE product pointer/length now that it is no longer set from interrupt context

05

Async Rust task state for orientation screen polled from main loop; potential lifetime concerns around callback closure passed to C

Risk score

Why this scored 24/100

Our methodology →
Potential impact 3/30
Exploitability 4/25
Stealth signal 5/15
Affected reach 6/15
Confidence 4/10
Evidence quality 2/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.