Understanding ARM TrustZone TEE and SMC Calls: Architecture, Conventions, and Implementation

Before diving into the article, the author poses several questions about Android devices: how many operating systems run on a phone, how to enter a secure OS, the relationship between exception levels and the secure OS, and the substance, conventions, and process of an SMC call.

With the proliferation of smartphones, the data stored on them (payment passwords, biometrics, copyrighted media, etc.) becomes increasingly valuable. To protect this data, ARM introduced TrustZone technology, which partitions CPU states and related hardware resources into Secure and Normal worlds. In Secure state, the CPU can access both Secure and Normal resources; in Normal state, it can only access Normal resources.

TrustZone enables the Trusted Execution Environment (TEE) – the Secure World – while the Rich Execution Environment (REE) runs in the Normal World (e.g., Android). OP‑TEE is an open‑source TEE OS that runs in the Secure World.

Key characteristics of TEE:

Hardware‑protected isolation from REE; communication occurs only through defined entry points.

High performance by using the full CPU.

Fast communication: TEE can read REE memory, but REE cannot read TEE‑protected memory.

When REE needs a TEE service, it first switches to a privileged mode in the Normal world (Linux kernel mode on Android), invokes an SMC (Secure Monitor Call), which saves the Normal‑world context, then transitions to Secure‑world privileged mode where the TEE executes the requested service.

Using OP‑TEE as an example, the interaction flow is:

CA opens a session via libteec , entering kernel EL1 and calling the TEE driver API.

The driver issues an SMC to EL3 (Secure Monitor).

The Secure Monitor parses the SMC command, locates the corresponding OP‑TEE service, and hands control to the OP‑TEE kernel.

OP‑TEE loads and validates the TA (Trusted Application).

The TA runs and returns results to the CA.

The article then delves into the SMC call itself.

SMC Instruction

The SMC instruction format is shown as SMC #<16‑bit‑value> . It can only be executed at EL1 or higher; user space cannot invoke it directly.

SMC Error Codes

For AArch32, error codes are returned in R0; for AArch64, they are returned in X0 (or W0 for 32‑bit values).

Parameter Passing Conventions

AArch32:

Function identifier – R0

Function arguments – R1‑R7

Return values – R0‑R7

R4‑R7 must be preserved unless they hold return values.

R8‑R14 are callee‑saved and must be preserved across SMC/HVC.

AArch64:

Function identifier – W0

Function arguments – X1‑X17

Return values – X1‑X17

X4‑X17 are callee‑saved unless they hold return values.

X18‑X30 are callee‑saved and must be preserved across SMC/HVC.

SMC Register Usage Tables (illustrated in the original figures) describe which registers are used for input, output, and preservation for both architectures.

SMC Service Identifier (OEN) Ranges and Function Identifier Ranges are defined in tables that map specific OEN values to services and reserve the 0x00000000‑0xFFFFFFFF space for future use.

SMC Return Values are signed integers where 0 indicates success and –1 indicates an unsupported call.

SMC Implementation in Code

The kernel header include/linux/arm-smccc.h defines the macro:

__arm_smccc_1_1("smc #0", __VA_ARGS__)

The macro expands to a low‑level assembly routine that saves the context, switches to EL3, and executes the SMC instruction. The implementation is shown in the figures (e.g., arm_smccc_smc declaration and definition).

SMC Call Types

Fast SMC : W0[31] == 1; interrupts are disabled, guaranteeing atomic execution.

Yielding (Standard) SMC : W0[31] == 0; interrupts remain enabled, allowing normal‑world interrupt handling.

Secure Monitor Startup Process

BL31 (the Secure Monitor) performs CPU initialization, runtime setup, hardware initialization (timer, UART, GIC), page‑table creation, image loading, interrupt framework setup, context preparation for different exception levels, and registers runtime services.

Service Registration

Macros such as DECLARE_RT_SVC create a descriptor structure placed in a special section ( rt_svc_descs ). The kernel iterates over this section to locate and register services.

SMC Handling Flow

When an SMC is invoked, the CPU traps to a synchronous exception handler ( sync_exception_aarch64 ), which expands to handle_sync_exception . This macro ultimately calls smc_handler64 , which:

Saves registers X0‑X29.

Uses X5 as a cookie and X6 as the context structure pointer.

Saves SPSR_EL3, ELR_EL3, SCR_EL3, etc.

Loads the service address into X15 and jumps to std_svc_smc_handler .

After service execution, calls el3_exit to restore the REE context.

The el3_exit routine restores SP_EL0, SPSR_EL3, ELR_EL3, CPTR_EL3, and general‑purpose registers before executing the eret instruction to return to EL1 (Linux kernel).

SMC Service Processing

The top‑level handler std_svc_smc_handler checks the SMC function identifier (SMC_fid). If it matches a PSCI command, the corresponding power‑management operation is performed; otherwise, the handler dispatches to the appropriate service based on the OEN.

PSCI (Power State Coordination Interface) covers CPU idle management, hot‑plug, secondary CPU boot, system shutdown, and reset.

Conclusion

The article starts from the motivation for using TEE, then thoroughly analyzes the REE‑TEE interaction, focusing on SMC fundamentals, ARM architecture conventions, exception levels, secure monitor boot flow, service registration, and assembly‑level code analysis. It notes that thread handling differs among TEE implementations and suggests further research on multi‑threaded TEE OS behavior.