Last edited one week ago

STM32MP15 OP-TEE overview

Applicable for STM32MP15x lines


1. STM32MP15 OP-TEE Overview[edit | edit source]

This section gives an overview of the OP-TEE core drivers (UPPERCASE in the figure) implemented for the STM32MP15 support, with their respective software frameworks (lowercase in the figure).

It is running in the Cortex-A7 secure context (Priviledge Level 1 Secure (PL1S)).

Due to the Armv7-A architecture, it runs a dedicated secure monitor which is running in Arm® Cortex® PL1S and which is providing Arm® Cortex® 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 Arm® Cortex®-M coprocessor management

The STM32MP15x lines  offer two profiles:

  • A minimal OP-TEE running in DDR (CFG_STM32MP1_OPTEE_IN_SYSRAM=n/CFG_WITH_PAGER=n) that only supports system resource management:
    CFG_STM32MP_PROFILE=system_services
    because OP-TEE in the DDR is not fully secure for the STM32MP15x lines .
  • A complete OP-TEE running in internal memory (CFG_STM32MP1_OPTEE_IN_SYSRAM=y/CFG_WITH_PAGER=y) including support of security features:
    CFG_STM32MP_PROFILE=secure_and_system_services.

As mentioned in the STM32 MPU OP-TEE overview, the various features can be independently activated according to customer needs.

The following figure provides an overview of the STM32MP15x lines  OP-TEE.

The components are grouped by functional domains.
Each OP-TEE framework is further described in the OP-TEE category articles.
Each STM32 MPU peripheral is introduced in the peripherals overview articles.
Both sections are reusing the same functional domain split.

The color code, explained in the legend, allows to see the code origin for each component.

Zoom out to OpenSTLinux distribution



2. STM32MP15 pager constraints[edit | edit source]

The STM32MP15x lines  cannot encrypt data stored in the DDR. Therefore the binary of OP-TEE and its secrets would be in plain text in the DDR to be able to execute it. This is a security concern and that's why we disable OP-TEE security features in this case and only allow the CFG_STM32MP_PROFILE=system_services. Since OP-TEE is executed in DDR (and not in SYSRAM) the following flag is disabled : CFG_STM32MP1_OPTEE_IN_SYSRAM=n. Using the DDR removes the memory constraints so the following flag is also disabled : CFG_WITH_PAGER=n.

To support the security features (CFG_STM32MP_PROFILE=secure_and_system_services), OP-TEE must run in internal RAM. The 256KB of secure internal RAM (SYSRAM) are dedicated to the OP-TEE (with CFG_STM32MP1_OPTEE_IN_SYSRAM=y). As OP-TEE OS requires more than 256KB RAM to execute, running OP-TEE in SYSRAM mandates the "pager" mode (CFG_WITH_PAGER=y) to extend secure memory size. This mode uses virtual memory mapping and a dynamic paging on demand mechanism to backup secure data into the DDR, protected by hash tables and software AES encryption keys.

To increase the OP-TEE pager performance on STM32MP15, you can increased the internal memory reserved by OP-TEE by using SRAMx.

When the CFG_STM32MP1_OPTEE_IN_SYSRAM=y/CFG_WITH_PAGER=y, the 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 one (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 the 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, refer to the OP-TEE documentation related to pager [1].

2.1. Impact on TF-A[edit | edit source]

Warning
When STM32MP15x lines  is configured with CFG_STM32MP_PROFILE=secure_and_system_services, TF-A configuration must reflect that OP-TEE is loaded in and boots from secure SYSRAM instead of external DDR. This requires TF-A to be configured with STM32MP1_OPTEE_IN_SYSRAM=1 (1 means enabled, 0 means disabled) for both T-A BL2 and TF-A FIP image.

2.2. Tuning memory configuration[edit | 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 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, 4 threads are reserved by default : 1 for SCMI, 1 for PSCI OSI and 2 for others OP-TEE services (2 threads are required to execute the xtests).
  • 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 | 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 the OP-TEE pager performances.

To assign one or more SRAMx memories to the OP-TEE secure firmware, one must change the OP-TEE Device Tree file to configure secure access only to these SRAMs and must change the 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
(256kB ecure RAM)

OP-TEE configuration switch: CFG_TZSRAM_SIZE=0x40000

SYSRAM
+ SRAM1
(384kB secure RAM)

OP-TEE configuration switch: CFG_TZSRAM_SIZE=0x60000

OP-TEE device tree file update:

 &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

OP-TEE device tree file update:

 &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

OP-TEE device tree file update:

 &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

OP-TEE device tree file update:

 &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.

3. References[edit | edit source]

  1. architecture/core.html#pager optee.readthedocs.io