Is this page helpful?

Architecture#

OP-TEE resides in a separate storage partition and boots as part of a chain of trust or a secure boot sequence. It creates two environments in a device with different security modes:

  • Non-Secure Environment (NSE): An environment for running software components in non-secure mode. This environment constitutes the “normal world.” A rich OS, such as Linux, typically runs in this environment.

  • Trusted Execution Environment (TEE): A separate environment that provides trusted operations and runs in a secure mode enforced by hardware. This environment constitutes the “secure world.” OP-TEE runs in this environment.

The normal-world OS and OP-TEE software operate in a client-server relationship, with OP-TEE as the server.

Bootloader allocates a dedicated carveout, TZ-DRAM, to run OP-TEE or another secure OS. All secure operations are initiated by a client application running in the non-secure environment. A trusted application, in the secure world, never initiates contact with the non-secure environment.

This diagram shows the relationships among the components:

Relationship among components in the normal world and the secure world

Note

The Jetson Orin series doesn’t have S-EL2 support, so Hafnium (S-EL2) in the preceding diagram applies only to the Jetson AGX Thor series.

Execution Steps#

  1. When a client application (CA) must perform a secure operation, it sends a request to a trusted application (TA) by calling functions in the TEE Client API library.

  2. The TEE Client API library routes the request to the OP-TEE Linux Kernel Driver.

  3. The OP-TEE Linux Driver routes the client application request to Arm Trusted Firmware (ATF).

  4. A monitor routes the request to Hafnium (for the Jetson AGX Thor series) or OP-TEE OS (for the Jetson Orin series).

    The Jetson Linux monitor implementation is based on ATF. For more information about ATF, see the Trusted Firmware-A (TF-A) project.

  5. For the Jetson AGX Thor series, Hafnium routes the request to OP-TEE OS.

  6. The OP-TEE OS determines which trusted application (TA) is to handle the request.

  7. The OP-TEE OS passes control to the TA to handle the request. When the TA needs to perform certain specific tasks, such as accessing secure storage or doing crypto operations, it can call functions defined in the TEE internal core API library to communicate with the OP-TEE OS and thereby accomplish these tasks.

  8. Upon completion, execution control returns along the reverse path to the client application, which receives a return value and any processed data.

On this page