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
In non blocking mode, the read function is expected
to return weather data is available for reading or not.
In case data are available but the size does not match
the expected size, the function read should return whatever
data is available.
Previously, the function was returning -1 with errno set
to EWOULDBLOCK even if the size of data in the buffer was
less than the requested size. It would only return the
available data if the size in the buffer was greater or equal
to the requested size.
The implementation of cdcacm_read is modified to return the avilable
data from the buffer even is the size is lesser than the requested
size.
morris
Xiao Xufeng
armando
yanzihan@espressif.com
wuzhenghui
Chen Jichang
Jiang Jiang Jian
Konstantin Kondrashov
Omar Chebib
Marius Vikhammer
Sudeep Mohanty
Mahavir Jain
Guillaume Souchere
wanckl
Jan Beran
Alexey Lapshin
harshal.patil
Martin Vychodil
Wang Meng Yang
Tomáš Rohlínek