- Place the APM HAL into TEE IRAM when `CONFIG_SECURE_TEE_EXT_FLASH_MEMPROT_SPI1`
is enabled, as APM violations related to SPI1 can occur with the flash cache disabled.
- Also fix an issue where flash protection tests were passing due to incorrect checks
- Decreased from 32KB to 24KB, keeping in mind the current maximum TEE heap
usage and some overhead
- Make the TEE panic handler logs concise, saving some DRAM
This commit removes the disabling of the LP Timer interrupt from the
bootloader clock configuration routine. This allows the LP Timer
interrupt to be visible to the LP Core after HP CPU boots up.
Closes https://github.com/espressif/esp-idf/issues/15751
* removed spi master in iram select for flash only firmware
* fixed memory issue in transaction init function
* fixed memory issue in transaction deinit function
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.
