- `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
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.
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.
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.
- Previously, only the U-mode interrupt threshold was raised in REE critical sections,
leaving M-mode at the lowest level.
- As a result, when a service call transitioned to M-mode, all interrupts were still
allowed to fire, including those that should have been masked.
- 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
- Fix incorrect setting in the edge interrupt acknowledgement API
- Avoid executing the service call dispatcher in the U-mode ecall,
rather execute `mret` to jump it
- Avoid `t1` register corruption when processing `ecall`
- Switch back to the bootloader stack from TEE stack after the
execution of the entire TEE initialization routine
- 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
Ashish Sharma
Laukik Hase
harshal.patil
Alexey Lapshin
Aditya Patwardhan
Xiao Xufeng
Alexey Gerenkov
Mahavir Jain
Jiang Jiang Jian