koolie_bd的博客

bl31中的runtime_svc_init函数会初始化OP-TEE对应的服务，通过调用该服务项的初始化函数来完成OP-TEE的启动。对于OP-TEE的服务项会通过DECLARE_RT_SVC宏在编译时被存放到rt_svc_des段中。该段中的init成员会被初始化成opteed_setup函数，由此开始进入到OP-TEE OS的启动。整个流程如图所示。

在bl2中触发安全监控模式调用后会跳转到bl31中执行，bl31最主要的作用是建立EL3运行态的软件配置，在该阶段会完成各种类型的安全监控模式调用ID的注册和对应的ARM核状态的切换，bl31运行在EL3。bl31的执行流程如图所示。

bl2镜像将为后续镜像的加载执行相关的初始化操作，主要是内存、MMU、串口以及EL3软件运行环境的设置，并且加载bl3x的镜像到内存中。通过查看bl2.ld.S文件可发现，bl2镜像的入口函数是该函数定义在bl2/aarch64/bl2_entrypoint.S文件中。该阶段的执行流程如图所示。

系统上电之后首先会运行ChipRom，之后会跳转到ATF的bl1中继续执行。bl1主要初始化CPU、设定异常向量、将bl2的镜像加载到安全RAM中，然后跳转到bl2中开始运行。bl1的主要代码存放在bl1目录中，bl1的链接文件是bl1/bl1.ld.s文件，该文件指定bl1的入口函数是bl1_entrypoint。AArch32的该函数定义在bl1/aarch32/bl1_entrypoint.S文件中，AArch64的该函数定义在bl1/aarch64/bl1_entrypoint.S文件中。

安全引导（Secure Boot）功能是指在系统的整个启动过程中，使用链式验证电子签名的方式来验证系统中重要镜像文件的可靠性，然后再加载镜像文件的引导过程。系统启动过程中的Bootloader、Linux内核、TEE OS的启动都由ATF（）来加载和引导。

Linux系统在启动的过程中会自动挂载OP-TEE的驱动，驱动挂载过程中会创建/dev/tee0和/dev/teepriv0设备。其中/dev/tee0设备将会被REE侧的用户空间的库（libteec）使用/dev/teepriv0设备将会被系统中的常驻进程tee_supplicant使用。

在optee4.6.0版本中编译目标主要在build/Makefile 和 build/common.mk中被定义，编译目标的依赖关系如图所示SPMC： 安全分区管理器核心MEASURED_BOOT_FTPM：支持基于 fTPM（Firmware Trusted Platform Module） 的安全启动测量功能。其中，buildroot这部分通过make_def_config.py对optee_examples、optee_client、optee_test、xen进行依赖。

是一个开源的 TEE 实现，主要用于基于 ARM TrustZone 技术的嵌入式设备。它为运行在“安全世界（Secure World）”中的可信应用（Trusted Applications, TA）提供了一个隔离的安全执行环境。其中一个关键特性就是：提供完整的 加密服务接口（Crypto API） ，支持多种加密算法和密钥管理机制。从TA到实际加密算法之间存在多个层级。大多数加密代码运行在TEE核心的内核模式下。

OP-TEE 的持久化机制允许 TA 将敏感数据安全地存储在非易失性存储器中，从而在设备重启后仍能恢复使用。这种机制常用于保护密钥材料或认证凭据，在包括移动支付、设备认证等场景中有广泛应用。部分 Android 设备可能利用类似机制来增强用户认证的安全性，但具体实现方式因设备而异。

共享内存（Shared Memory）是非安全世界（Non-secure World）与安全世界（Secure World）之间共享的内存区域，用于实现两个世界间的数据传输。其分配与管理完全由非安全世界（即Linux OP-TEE驱动）负责，安全世界仅处理具体的共享缓冲区而非内存池。

在OP-TEE中，TEEC_InvokeCommand() 承担着核心功能调用的角色。虽然 TEEC_OpenSession 和 TEEC_CloseSession 负责会话的创建与销毁，但真正的功能执行主要依赖于 TEEC_InvokeCommand，它通过指定的命令ID（Command ID）触发TA（Trusted Application）中的具体操作。

当REE中的CA被执行时都发生了哪些操作，又是何时调用TA的呢？