If Task WDT is initialised but not start, the call to esp_timer_stop() in
the reconfigure path returns ESP_ERR_INVALID_STATE and reconfiguring the
Task WDT fails. This isn't the case when the Timer Group is used for Task
WDT.
(This failure cascades into the failure due to disabled interrupts, fixed
in the parent commit.)
Signed-off-by: Angus Gratton <angus@redyak.com.au>
- Failures were being masked as function always returned ESP_OK
- In the failure path the spinlock was not unlocked, so interrupts
became permanently disabled.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
When DMA keep writing the memory, some data may be corrupted after reset. For example, the stack of bootloader may be overwritten and failed to boot until a higher scope of reset (Core).
This commit updates all RTC WDT contexts to be local instead of global
to avoid race conditions when both cores enter the panic handler
simultaneously.
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.
This commit updates the following:
- Updates the panic handler to use only the RTC WDT to reset the system.
- Refactors some of the panic handler code.
- Updates Bluetooth files where in they now feed the WDTs instead of
reconfiguring them.
- Removes some unnecessary configuration of WDTs from various files.
- Added a unit test to verify that the system does not lock up when the
panic handler is stuck.
- Updates the memprot unit tests to work with the refactored panic
handler.
Closes https://github.com/espressif/esp-idf/issues/15166
Closes https://github.com/espressif/esp-idf/issues/15018
Closes https://github.com/espressif/esp-idf/issues/10110
