twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 52 Pull Requests Actions 2 Packages Releases 15 Activity

OTA: the firmware rolls itself back; the bootloader doesn't

Browse Source 
A deliberately crashing update looped forever on the device: the
prebuilt bootloader ignores ESP_OTA_IMG_PENDING_VERIFY despite the
app-side rollback config. UpdateService::bootGuard() now runs first in
setup(): it counts starts on Probation in NVS and, on the second
unconfirmed start, marks the image invalid and reboots into the
previous one. Confirming (or the Wi-Fi rollback) resets the counter.
ADR 0003 records the limit: a crash in the first milliseconds still
needs USB.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
This commit is contained in:
twisla
2026-10-03 21:48:39 +02:00
co-authored by Claude Opus 5.5
parent de5931210f
commit 45542dcbff
6 changed files with 34 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/adr/0003-own-signature-check-not-secure-boot.md
+1
View File
@@ -9,3 +9,4 @@ We chose this over the ESP32's hardware Secure Boot. Secure Boot is enforced by
- Someone with physical USB access can still flash anything. Only Wi-Fi and SD card updates are guarded.
- **Losing the private key** means the next update has to go over USB, carrying a new public key.
- P-256 rather than Ed25519, because the firmware's TLS library (mbedTLS) already verifies it, so it costs no extra code.
- **Rollback is done by the firmware, not the bootloader.** On the device, the prebuilt bootloader that PlatformIO flashes did not roll back a crashing update, even though the app's configuration enables it. So the firmware counts its own boots on Probation, very first thing in `setup()`, and reverts itself on the second unconfirmed start. A crash before that counter is written (the first few milliseconds) would not be caught: recovery is then over USB.