Implementing Secure Monitor Calls for World Transitions

1. The Secure Monitor Call (SMC) as a Standardized API

An SMC is not just an arbitrary jump; it's a synchronous exception that triggers a mode switch to EL3. To ensure interoperability between different software components (e.g., a standard Linux kernel and a proprietary secure firmware), ARM defines the SMC Calling Convention (SMCCC). This convention standardizes how services are requested, how parameters are passed, and how results are returned.

The reference implementation for this architecture on A-class processors is the Trusted Firmware-A (TF-A) project, which provides the EL3 monitor firmware (known as BL31).

As the video explained, the SMC layer is a well-defined interface. Let's dig into the details of that interface.

To summarize the key points from that reading:

• An SMC is initiated by the smc instruction.
• The W0 (or X0) register holds the SMC Function Identifier (smc_fid).
• The smc_fid is a 32-bit value that encodes:
  • Call Type (bit 31): 0 for Fast Call, 1 for Yielding/Standard Call.
  • Calling Convention (bit 30): 0 for SMC32 (32-bit args), 1 for SMC64 (64-bit args).
  • Owning Entity Number (OEN, bits 23-16): Identifies the service owner (e.g., ARM Architecture, SiP, OEM, Trusted OS).
  • Function Number (bits 15-0): The specific function being called within that service.
• Arguments are passed in registers X1 through X7.
• Return values are passed back in X0 through X7.

This standardized structure allows the Secure Monitor to act as a router, directing incoming requests to the correct service handler.

2. Implementing the SMC Handler in EL3

When an smc instruction is executed in the Normal World (e.g., at EL1), the processor takes a synchronous exception to EL3. The Secure Monitor's exception handler must then perform the following steps:

1. Identify the Exception: Read the Exception Syndrome Register (ESR_EL3) to confirm the cause was an SMC instruction.
2. Decode the Request: Read the smc_fid from register X0.
3. Dispatch to Service: Based on the OEN in the smc_fid, forward the call to the appropriate registered service handler.
4. Execute and Return: The service handler performs its function and prepares the return values in registers X0-X7 before returning from the exception.

The following resource shows a simplified assembly implementation of this logic.

In a full-featured firmware like TF-A, this raw assembly logic is wrapped in a C framework. Services register themselves with the monitor during initialization, providing a function pointer to their handler.

Your experience with AUTOSAR BSW integration is relevant here. Just as you integrate different modules (e.g., Can, Com, PduR) that register their services with the RTE, here you have different secure services (PSCI, SiP, etc.) that register their SMC handlers with the EL3 runtime framework.

3. Implementing the World Switch

Not all SMCs result in a world switch. A simple request might be handled entirely within EL3. However, if the request is for a complex service provided by a Trusted OS (running at S-EL1), the Secure Monitor must perform a full context switch.

The key to the world switch is the Secure Configuration Register, SCR_EL3. Its NS (Non-Secure) bit determines the security state of the lower exception levels.

• SCR_EL3.NS = 1: EL0/1/2 are in the Non-secure state.
• SCR_EL3.NS = 0: EL0/1/2 are in the Secure state.

The process to switch from Normal to Secure world is:

1. Receive the SMC in EL3.
2. Save the complete context of the Normal World (GPRs, SP_ELx, SPSR_ELx, ELR_ELx).
3. Set up the entry parameters for the Secure World (e.g., in registers X0-X4).
4. Modify SCR_EL3 to clear the NS bit (bic x0, x0, #1).
5. Set SPSR_EL3 to the desired state for entering the Secure World (e.g., target S-EL1).
6. Set ELR_EL3 to the entry point address in the Secure World.
7. Execute eret. The processor resumes at ELR_EL3 in the new security state.

This mechanism is used in many real-world automotive scenarios. For instance, writing to One-Time Programmable (OTP) fuses for configuration or key storage is a highly sensitive operation. A non-secure bootloader like U-Boot would use an SMC to request the ARM Trusted Firmware (ATF) to perform the write.

#include <stdint.h>

// Construct the SMC Function ID
// SMC64 Fast Call: Type=0 (bit31), CC=1 (bit30)
// OEN=50 (0x32), Fn_Num=123 (0x7B)
#define SECURE_SERVICE_SMC_FID 0x4000327B

uint64_t call_secure_service(uint64_t arg1) {
    register uint64_t r0 __asm__("x0") = SECURE_SERVICE_SMC_FID;
    register uint64_t r1 __asm__("x1") = arg1;

    // The 'smc #0' instruction is executed. The immediate value is ignored by the CPU
    // but can be used by the handler. Conventionally, it's 0.
    // The registers x0 and x1 are specified as both input and output ('+r').
    __asm__ volatile (
        "smc #0"
        : "+r"(r0), "+r"(r1) // Output operands
        : // Input operands (already specified in output)
        : "x2", "x3", "x4", "x5", "x6", "x7", "memory", "cc" // Clobbered registers
    );

    // The return value from the secure service will be in x0.
    return r0;
}

4. A Practical Look at World Transitions (Cortex-M)

While we've focused on Cortex-A's SMC instruction, it's insightful to see the equivalent process on a Cortex-M processor with TrustZone-M. The mechanism is different (SG instruction via "veneer" functions instead of SMC), but the principle of a controlled transition from non-secure to secure code is identical. Watching a debug session can make these abstract concepts very concrete.

5. Interview Corner

Q1: Walk me through the life of an SMC, from a non-secure Linux application to the execution of a secure service and back.
A:

1. The Linux application makes a system call (e.g., via an ioctl on a specific device driver).
2. The kernel driver, running in EL1, prepares the registers according to the SMCCC: X0 gets the smc_fid, and X1-Xn get the arguments.
3. The driver executes the smc #0 instruction. This causes a synchronous exception to EL3.
4. The Secure Monitor (e.g., TF-A's BL31) starts execution at its exception vector. It reads ESR_EL3 to confirm an SMC occurred.
5. It decodes the smc_fid from X0 to identify the service owner (OEN) and function number.
6. It dispatches the call to the registered handler for that OEN.
7. The handler executes. If it needs a Trusted OS, the monitor saves the non-secure context, modifies SCR_EL3.NS to 0, sets up the S-EL1 entry context, and executes eret.
8. The Trusted OS at S-EL1 performs the service. Upon completion, it makes an SMC to return to EL3.
9. The monitor then restores the non-secure world context, sets SCR_EL3.NS back to 1, and executes eret to return to the Linux driver at EL1, right after the original smc instruction.
10. The driver receives the return values in X0-Xn, and returns the result to the user-space application.

Q2: Why is the SMC Calling Convention (SMCCC) so important for the TrustZone ecosystem?
A: It provides a standardized, interoperable interface between software from different vendors. An SoC vendor can provide EL3 firmware (the monitor), a separate company can provide a Trusted OS, and a third party like Canonical can provide the Normal World OS (Ubuntu/Linux). The SMCCC ensures they can all communicate correctly without needing to be tightly coupled. It decouples the service requester from the service provider, which is essential for building complex, modular systems.

Q3: You're debugging a system where SMCs to a custom SiP service are failing with an "Unknown SMC Function ID" error (0xFFFFFFFF). What are the likely causes in the EL3 firmware?
A: The error code SMC_UNK means the monitor doesn't have a handler for that specific smc_fid. The likely causes are:

• Registration Failure: The SiP service's _setup function failed during cold boot, so the framework never registered its handler. Check the boot logs for initialization errors.
• Incorrect OEN Range: The DECLARE_RT_SVC macro for the SiP service might have the wrong _start or _end OEN values, so the incoming smc_fid doesn't fall within its claimed range.
• Handler Logic Error: The service's _smch handler itself is incorrectly rejecting a valid function number within its range, perhaps due to a bug in its validation logic.
• Call Type Mismatch: The call is being made as a Yielding call, but the service was only registered for SMC_TYPE_FAST.

Conclusion

Today we moved from the theory of TrustZone to the practical implementation of its core communication mechanism. You've seen how a simple instruction, when governed by a robust convention and handled by well-structured firmware, can create a secure gateway between two isolated worlds.

Key Takeaways:

• World transitions are initiated via the smc instruction, which triggers a synchronous exception to EL3.
• The SMC Calling Convention (SMCCC) standardizes how smc_fid, arguments, and return values are passed in registers.
• The smc_fid contains the Owning Entity Number (OEN), which allows the Secure Monitor to route the call to the correct service (e.g., PSCI, SiP, Trusted OS).
• The Secure Monitor handler in EL3 is responsible for decoding the SMC, dispatching it, and potentially orchestrating a world switch by modifying SCR_EL3.NS and performing a context switch.
• Frameworks like TF-A provide a C-level abstraction for registering and handling SMC services.

Next Lesson Preview:
An SMC allows us to enter the Secure World, but how do we trust the code that's running there in the first place? In our next lesson, we will explore the principles of a secure boot process and the chain of trust, ensuring that the system starts up in a known, secure state from the very first instruction.