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.
- `bootloader_flash_execute_command_common`: whitelist the flash command
opcodes the REE actually uses; reject the rest
- `spi_flash_hal_* services`: a forged `host->driver` could hijack TEE
control flow since the HAL dispatches through it, so swap
`host->driver` to a TEE-rodata vtable around each HAL call
- Deny partition table and bootloader writes by default and permit
bootloader writes only when explicitly enabled via
`CONFIG_SPI_FLASH_DANGEROUS_WRITE_ALLOWED` option
- Protect the TEE-assigned interrupt pin configuration against REE
- Validate nested DS context pointers in start/finish_sign and bound
the result copy to the SoC max signature size
- Fix the stack usage in service dispatcher argument parsing
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.
- Unset IDF_BUILD_V2 in subproject/CMakeLists.txt before including
project.cmake so the nested esp_tee ExternalProject cmake stays on
cmakev1.
- Read PARTITION_TABLE_BIN_PATH as a generator expression under
IDF_BUILD_V2 to defer the lookup to CMake's generate phase.
A typical scenario is: when XIP on PSRAM enabled, compiler optimization level is Os. Under certain binary layout, boot hangs and backtrace points to `esp_sleep_config_gpio_isolate`.
The root cause is that, during PSRAM initialization, it calls esp_gpio_reserve, which happens to place before the reported function. However, after call, there is no barrier before the clock adjustment in `mspi_timing_enter_low_speed_mode`. The clock gets changed when the cache is still fetching data, resulting in the corrupted data in the end of the cache line.
This commits add spi_flash_disable_cache as a barrier to make sure the cache transactions is finished before the clock switch.
The TLSF ROM patch code (rom_patch_tlsf.c, rom_patch_multi_heap.c),
their headers, and the per-target *.rom.heap.ld linker scripts are
semantically owned by the heap component, not esp_rom. Move them
accordingly:
- components/esp_rom/patches/esp_rom_tlsf.c
→ components/heap/rom_patches/rom_patch_tlsf.c
- components/esp_rom/patches/esp_rom_multi_heap.c
→ components/heap/rom_patches/rom_patch_multi_heap.c
- components/esp_rom/include/esp_rom_tlsf.h
→ components/heap/rom_patches/include/rom_patch_tlsf.h
- components/esp_rom/include/esp_rom_multi_heap.h
→ components/heap/rom_patches/include/rom_patch_multi_heap.h
- components/esp_rom/<target>/ld/<target>.rom.heap.ld (×8)
→ components/heap/port/<target>/ld/<target>.rom.heap.ld
Update heap/CMakeLists.txt to:
- use target_linker_script() directly for *.rom.heap.ld
- guard post-registration ROM patch setup with NOT BOOTLOADER_BUILD
- drop stale CONFIG_HEAP_TLSF_CHECK_PATCH symbol reference
- drop esp_rom_include_multi_heap_patch from TLSF_CHECK_PATCH guard
Remove the corresponding entries from esp_rom/CMakeLists.txt.
TEE secure-service handlers had two bugs letting REE bypass
pointer-region validation:
1. valid_addr = instead of valid_addr &= in AEAD encrypt/decrypt
and DS sign handlers, clobbering prior failed checks.
Impact: REE writes to TEE DRAM via DS signature output, or reads
TEE DRAM via AEAD output.
2. data->rsa_length dereferenced before data is validated in DS sign
and DS start_sign handlers.
Fix: use &= for subsequent checks, add early return after initial
data pointer check in DS handlers.
- Using PMA, the TEE IRAM is marked as R/X while TEE DRAM is marked as R/W.
Moving the internal memory secure service call table from DRAM to IRAM
makes it immutable.
- Fix intermittent TEE stack underflow test failures
- Fix out-of-bounds access Coverity report from the attestation
component
- Add appropriate checks and asserts for TEE flash memory regions'
sizes
This commit reorganizes SPI flash header files to better reflect their
visibility and intended usage:
1. Rename `esp_flash_port/` to `esp_flash_chips/`:
- Better reflects that these headers are for chip driver implementations
- All chip driver headers moved to `esp_flash_chips/` directory
- Added README.md explaining semi-public nature of these headers
2. Move internal headers to `esp_private/`:
- `esp_flash_internal.h` -> `esp_private/esp_flash_internal.h`
- `memspi_host_driver.h` -> `esp_private/memspi_host_driver.h`
3. Move chip driver related headers to `esp_flash_chips/`:
- `esp_private/esp_flash_types.h` -> `esp_flash_chips/esp_flash_types.h`
- `spi_flash/spi_flash_defs.h` -> `esp_flash_chips/spi_flash_defs.h`
- `spi_flash_override.h` -> `esp_flash_chips/spi_flash_override.h`
- All `spi_flash_chip_*.h` headers moved to `esp_flash_chips/`
4. Code improvements:
- Remove unused includes (e.g., `spi_flash_override.h` from `cache_utils.c`)
- Use public API `esp_flash_get_size()` instead of direct member access
- Add `esp_flash_is_quad_mode` to linker.lf for IRAM placement
5. Documentation updates:
- Add README.md in `esp_flash_chips/` explaining semi-public headers
- Update programming guide with warnings about internal headers
- Update both English and Chinese documentation
6. Update all references across the codebase:
- Update includes in `spi_flash` component
- Update `bootloader_support`, `app_update`, `esp_tee`, `espcoredump`
- Update example projects
Breaking changes:
- Headers moved to new locations require include path updates
- `custom_flash_driver` example temporarily disabled until external
components are updated
- Increased the TEE stack when secure boot is enabled
- Also, generate a build error when the generated TEE binary image size is
greater than the TEE partition size
