Add SOC_DEBUG_HAVE_OCD_STUB_BINS for esp32c5, esp32c61, esp32h4,
esp32h21, esp32p4, and esp32s31. Update TEE linker scripts with
correct esp_tee_app_config offsets for the 0x3000 stub reservation
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
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.
