mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-02 11:10:54 +03:00
feat(esp_tee): Add support for flash memory isolation and protection (SPI1)
This commit is contained in:
@@ -100,10 +100,6 @@ External Memory (Flash)
|
||||
|
||||
Designated partitions in the external flash are reserved for the TEE, serving various purposes, including TEE code execution via XIP, secure storage, and OTA data. The PMS safeguards these partitions from unauthorized access, with the APM module protecting the MMU and SPI1 controller registers, and the PMP securing the cache.
|
||||
|
||||
.. note::
|
||||
|
||||
Flash memory protection is under development and will be introduced in the next revision of ESP-TEE.
|
||||
|
||||
.. figure:: ../../../_static/esp_tee/{IDF_TARGET_PATH_NAME}/esp_tee_flash_layout.png
|
||||
:align: center
|
||||
:scale: 80%
|
||||
@@ -112,6 +108,53 @@ Designated partitions in the external flash are reserved for the TEE, serving va
|
||||
|
||||
ESP-TEE: Flash Memory Map for {IDF_TARGET_NAME}
|
||||
|
||||
.. _tee-flash-prot-scope:
|
||||
|
||||
**Flash Protection - Virtual and Physical Access**
|
||||
|
||||
The key interfaces for flash memory protection are the cache connected to SPI0, which provides virtual access to flash memory, and the SPI1 controller, which provides physical access. By default, the cache and the MMU registers are secured by the PMS, preventing virtual access to the TEE-related flash partitions from the REE.
|
||||
|
||||
When :doc:`Flash Encryption <../flash-encryption>` is enabled, the REE can still access TEE flash regions via SPI1, but read operations will return encrypted data. Since neither the REE nor TEE has direct access to the flash encryption key, this prevents attackers from inferring TEE contents through direct reads.
|
||||
|
||||
Additionally with :ref:`Secure Boot <secure_boot-guide>` enabled, any unauthorized modifications to the TEE firmware will be detected during boot, causing signature verification to fail. Thus, the combination of Flash Encryption and Secure Boot provides a robust level of protection suitable for most applications.
|
||||
However, do note that while the TEE firmware integrity is protected, other TEE partitions (e.g., :doc:`Secure Storage <tee-sec-storage>`, :ref:`TEE OTA data <tee-ota-data-partition>`) can be modified through direct writes.
|
||||
|
||||
For stronger isolation, you can enable :ref:`CONFIG_SECURE_TEE_EXT_FLASH_MEMPROT_SPI1`, which completely blocks access to all TEE flash regions via SPI1 for the REE. With this setting, all SPI flash read, write, and erase operations are routed through service calls to the TEE. While this option provides enhanced security, it introduces some performance overhead.
|
||||
|
||||
The table below shows the rough time taken to read and write to a 1MB partition in 256B chunks with :doc:`../../api-reference/storage/partition`, highlighting the impact of ESP-TEE and the :ref:`CONFIG_SECURE_TEE_EXT_FLASH_MEMPROT_SPI1` configuration.
|
||||
|
||||
.. list-table:: Flash Protection: Performance Impact
|
||||
:header-rows: 1
|
||||
|
||||
* - Case
|
||||
- Read (ms)
|
||||
- Read Δ (ms)
|
||||
- Read Δ (%)
|
||||
- Write (ms)
|
||||
- Write Δ (ms)
|
||||
- Write Δ (%)
|
||||
* - ESP-TEE disabled
|
||||
- 262.01
|
||||
- -
|
||||
- -
|
||||
- 3394.23
|
||||
- -
|
||||
- -
|
||||
* - ESP-TEE enabled
|
||||
- 279.86
|
||||
- +17.85
|
||||
- +6.81%
|
||||
- 3415.64
|
||||
- +21.41
|
||||
- +0.63%
|
||||
* - ESP-TEE + SPI1 protected
|
||||
- 359.73
|
||||
- +97.72
|
||||
- +37.33%
|
||||
- 3778.65
|
||||
- +384.42
|
||||
- +11.32%
|
||||
|
||||
Peripherals
|
||||
~~~~~~~~~~~
|
||||
|
||||
|
||||
@@ -67,10 +67,6 @@ The TEE Secure Storage feature supports two modes (:ref:`CONFIG_SECURE_TEE_SEC_S
|
||||
|
||||
All the assets pertaining to the TEE secure storage are protected by the APM peripheral and thus, are inaccessible to the REE application. Any attempt to directly access them would result in a system fault.
|
||||
|
||||
.. note::
|
||||
|
||||
Flash memory protection is currently not implemented - it will be added soon in the next revision of the ESP-TEE framework.
|
||||
|
||||
.. note::
|
||||
|
||||
- Currently, the TEE secure storage supports the storage of two types of cryptographic keys:
|
||||
|
||||
@@ -71,10 +71,6 @@ Memory Allocation
|
||||
|
||||
ESP-TEE divides the memory into separate regions for the TEE and REE, allocating part of the internal SRAM and external flash memory to the TEE. This separation safeguards sensitive data and operations within the TEE, preventing unauthorized access from the REE.
|
||||
|
||||
.. note::
|
||||
|
||||
Flash memory protection is under development and will be introduced in the next revision of ESP-TEE.
|
||||
|
||||
.. _tee-internal-memory:
|
||||
|
||||
Internal Memory (SRAM)
|
||||
@@ -105,10 +101,14 @@ Example partition table is given below: ::
|
||||
nvs, data, nvs, 0x150000, 24K,
|
||||
phy_init, data, phy, 0x156000, 4K,
|
||||
|
||||
.. note::
|
||||
.. important::
|
||||
|
||||
The partition following the last TEE-related partition must be aligned to the configured MMU page size. This alignment is required to prevent secure boot verification failures when validating the user application (REE) image.
|
||||
|
||||
.. note::
|
||||
|
||||
For more details on the default policy and scope of flash memory protection with ESP-TEE, refer to the :ref:`Flash Protection - Virtual and Physical Access <tee-flash-prot-scope>` section from the advanced guide.
|
||||
|
||||
.. _tee-secure-services:
|
||||
|
||||
Secure Services
|
||||
|
||||
Reference in New Issue
Block a user