1. STM32MP15 OP-TEE Overview[edit source]
This section gives an overview of OP-TEE core drivers (UPPERCASE in the figure) implemented for the STM32MP13 support, with their respective software frameworks (lowercase in the figure).
It is running in Cortex-A7 secure context (EL1S execution level).
Due to Armv7-A architecture, It also runs a dedicated secure monitor which is running in Cortex-A7 EL3 and which is providing Cortex-A7 cluster low power functionalities via PSCI interface.
OP-TEE is in charge of:
- System resources management
- Internal and external regulators
- Clock tree (PLLs and Root clocks)
- System peripheral clock gating
- Oscillators calibration
- Firewall configuration and dynamic management
- RNG access
- OTP access
- Wakeup pins
- Secure services
- Cryptography via Global Platform (GP) API
- PKCS#11
- Trusted UI
- StMM for secure UEFI
- fTPM (firmware TPM) for TPM2 services
- OTP for provisioning
- SecCopro for secure coprocessor management
STM32MP15x lines 
offers two profiles:
- A minimal OP-TEE running in DDR that only supports system resource management:
CFG_STM32MP_PROFILE=system_services. - A complete OP-TEE running in internal memory including support of security features:
CFG_STM32MP_PROFILE=secure_and_system_services.
As mentioned STM32 MPU OP-TEE overview, the different features can be independently activated according to customer needs.
The following figure provides an overview of STM32MP15x lines OP-TEE.
The components are grouped per functional domains.
Each OP-TEE framework is further described in OP-TEE secure OS category articles.
Each STM32 MPU peripheral is introduced in peripherals overview articles.
Both those sections are reusing the same functional domain split.
The color code, explained in the legend, allows to see the code origin for each component.
2. STM32MP15 pager constraints[edit source]
STM32MP15x lines does not encrypt data stored in the DDR, therefore running OP-TEE in DDR is not fully secure. STM32MP15x lines embed a 256kByte secure internal RAM dedicated to OP-TEE: SYSRAM. Because OP-TEE OS requires more than 256Ko RAM to execute, when executing OP-TEE in SYSRAM we must enable OP-TEE's "pager" mode (CFG_WITH_PAGER=y) to extend secure memory size using virtual memory mapping and a dynamic paging on demand mechanism to backup secure data into DDR, protected by hash tables and software AE encryption keys.
When CFG_WITH_PAGER=y, OP-TEE boot image is made of 2 binary images: one (the unpaged part) is loaded at the beginning of the SYSRAM by the FSBL, the second (the pageable part) is loaded in DDR by the FSBL, in a DDR area that can be accessed by the CPU secure world.
OP-TEE OS manages low power mode by saving an encrypted image of the SYSRAM content in DDR before it is suspended. OP-TEE restores this content back into the SYSRAM when it resumes from the suspended state. This sequence is achieved using CPU instructions and encryption keys saved in the secure and retained backup SRAM.
For more information on OP-TEE's pager implementation and integration, one can refer to the OP-TEE documenation related to pager
[1]
2.1. Impact on TF-A[edit source]
2.2. Tuning memory configuration[edit source]
There are few OP-TEE configuration directives that impact the size footprint in internal memory of resident data. The bigger the resident data is, the small the pager page pool will be. When OP-TEE executes in only SYSRAM only, the pager pool size is likely below 128kB and these configuration directives must be tuned with care.
- CFG_CORE_HEAP_SIZE sets OP-TEE core heap size in byte. 48kByte to 64kByte should be enough.
- CFG_NUM_THREADS sets the number of thread contexts provisioned in OP-TEE core. Each thread context consumes about 4kB of resident memory. On STM32MP15x lines with pager enabled, using 3 thread contexts (default value) can be a wise choice.
- CFG_TEE_CORE_DEBUG enables or not debug mode (assertion and extra checks). These consume a few dozen of kByte of resident memory.
2.3. OP-TEE in SYSRAM and SRAMx[edit source]
STM32MP15x lines embed internal RAMs (SRAMx) initially intended for the co-processor. It is possible however to secure these SRAMs and assign them to OP-TEE pager to enlarge its pager page pool in order to enhance OP-TEE pager performances.
To assign one or more SRAMx memories to OP-TEE secure firmware, one shall change the OP-TEE DeviceTree file to configure secure access only to these SRAMs and shall change OP-TEE configuration switch CFG_TZSRAM_SIZE according to the desired size secure RAM size.
Because OP-TEE pager requires a physically contiguous page pool memory area, not all combinations of SRAM1/SRAM2/SRAM3/SRAM4 can be assigned to OP-TEE pager. Possible combinations are listed in the table below:
| RAMs assigned to OP-TEE | Configuration |
|---|---|
| SYSRAM + SRAM1 (384kB secure RAM) |
OP-TEE configuration switch: CFG_TZSRAM_SIZE=0x60000 &etzpc {
st,decprot = <
...
DECPROT(STM32MP1_ETZPC_SRAM1_ID, DECPROT_S_RW, DECPROT_LOCK)
>;
|
| SYSRAM + SRAM1 + SRAM2 (512kB secure RAM) |
OP-TEE configuration switch: CFG_TZSRAM_SIZE=0x80000 &etzpc {
st,decprot = <
...
DECPROT(STM32MP1_ETZPC_SRAM1_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM2_ID, DECPROT_S_RW, DECPROT_LOCK)
>;
|
| SYSRAM + SRAM1 + SRAM2 + SRAM3 (576kB secure RAM) |
OP-TEE configuration switch: CFG_TZSRAM_SIZE=0x90000 &etzpc {
st,decprot = <
...
DECPROT(STM32MP1_ETZPC_SRAM1_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM2_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM3_ID, DECPROT_S_RW, DECPROT_LOCK)
>;
|
| SYSRAM + SRAM1 + SRAM2 + SRAM3 + SRAM4 (640kB secure RAM) |
OP-TEE configuration switch: CFG_TZSRAM_SIZE=0xa0000 &etzpc {
st,decprot = <
...
DECPROT(STM32MP1_ETZPC_SRAM1_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM2_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM3_ID, DECPROT_S_RW, DECPROT_LOCK)
DECPROT(STM32MP1_ETZPC_SRAM4_ID, DECPROT_S_RW, DECPROT_LOCK)
>;
|
Note that configuration DECPROT_LOCK can be replaced with DECPROT_UNLOCK if the firewall configuration is not to be locked for some platform reason.