ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
Currently, REE SPI flash HAL operations are routed as service calls to TEE,
but the TEE implementation incorrectly uses ROM APIs instead of HAL APIs.
This leads to issues and is not the recommended approach.
- Ensure bound checks correctly handle all scenarios, including
when a requested operation's (SPI0/1) range fully contains the
TEE-protected region.
- Disable delegation of INTWDT timeout and Cache error interrupts as they reset
the device after the panic handler
- Rename `tee_test_fw` app configs for better CI tracking
- Decrease the lower bound of TEE I/DRAM config options
- Trim the TEE test-apps build
- Improve the TEE/REE OTA pytest script with additional checks
- Fix build issues when `tee_sec_storage`/`tee_ota_ops` are a
a part of the project build but ESP-TEE is disabled
- 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
- Remove `mret` for jumping to the service call dispatcher; instead, enable
interrupts and execute directly
- Fix potential corruption of the `t3` register when returning from a service
call
- Simplify the secure service dispatcher function
Also:
- Split the secure service table into two parts: one DRAM-resident and the
other DROM-resident. The former holds the services invoked when the cache is
disabled or suspended while the latter holds rest of the services.
harshal.patil
Aditya Patwardhan
Laukik Hase
Fu Hanxi
Jiang Jiang Jian
Chen Ji Chang
igor.udot