5cdc53df23
This change addresses a rare but critical issue observed on certain ESP32-C3 and ESP32-S3 devices, where secure boot verification intermittently fails due to improper cleanup of crypto peripherals during a restart. Background – Restart Behavior in IDF ------------------------------------ In ESP-IDF, when the device restarts (via `esp_restart()` or due to a panic/exception), a partial peripheral reset is performed followed by a CPU reset. However, until now, crypto-related peripherals were not included in this selective reset sequence. Problem Scenario ---------------- If a restart occurs while the application is in the middle of a bignum operation (i.e., using the MPI/Bignum peripheral), the ROM code may encounter an inconsistent peripheral state during the subsequent boot. This leads to transient RSA-PSS secure boot verification failures. Following such a failure, the ROM typically triggers a full-chip reset via the watchdog timer (WDT). This full reset clears the crypto peripheral state, allowing secure boot verification to succeed on the next boot. Risk with Aggressive Revocation ------------------------------- If secure boot aggressive revocation is enabled (disabled by default in IDF), this transient verification failure could mistakenly lead to revocation of the secure boot digest. If your product configuration has aggressive revocation enabled, applying this fix is strongly recommended. Frequency of Occurrence ----------------------- The issue is rare and only occurs in corner cases involving simultaneous use of the MPI peripheral and an immediate CPU reset. Fix --- This fix ensures that all crypto peripherals are explicitly reset prior to any software-triggered restart (including panic scenarios), guaranteeing a clean peripheral state for the next boot and preventing incorrect secure boot behavior.
System Notes
Timekeeping
The following are the timekeeping mechanisms available and their differences:
- System time (
esp_system_get_time)
Time with the origin at g_startup_time. The implementation is not handled by esp_system,
but it does provide a default implementation using RTC timer. Currently, esp_timer
provides system time, since the hardware timers are under the control of that
component. However, no matter the underlying timer, the system time provider
should maintain the definition of having the origin point at g_startup_time.
esp_timertime (esp_timer_get_time)
This is the time read from an underlying hardware timer, controlled through config. Origin is at the point where the underlying timer starts counting.
newlibtime (gettimeofday)
Timekeeping function in standard library. Can be set (settimeofday) or moved forward/backward (adjtime);
with the possibility of the changes being made persistent through config.
Currently implemented in terms of system time, as the point of origin is fixed.
If persistence is enabled, RTC time is also used in conjuction with system time.
- RTC time (
esp_rtc_get_time_us)
Time read from RTC timer.
Brownout
on some boards, we name BOD1 as ana_bod, to unify the usage, using BOD1 in following passage.
BOD1 will be a little faster then BOD0, but BOD0 can be widely used(can reset rf, flash, or using interrupt, etc.) So, in IDF code, we use BOD1 in bootloader and BOD0 in the app.