当前位置：首页 > news >正文

TEE-OS学习轨迹第十四篇：OP-TEE OS 源码分析部分（一）整体架构

news 2026/6/23 0:05:39

前言

我们拆解了ATF的完整启动链路与安全启动实现，而BL32阶段的OP-TEE，正是安全世界的核心业务载体——它运行在Secure EL1特权级，是可信应用（TA）的运行操作系统，也是Android Keystore、Widevine L1、安全支付等所有上层安全业务的底层执行环境。

本篇基于OP-TEE 3.x LTS版本，结合你当前QEMU virt平台的实际运行日志，从启动流程、线程模型、内存隔离、TA生命周期、加密框架、安全加固六个维度，逐层拆解安全世界操作系统的核心实现。

一、OP-TEE整体架构与启动全链路

OP-TEE是遵循GlobalPlatform TEE标准的开源可信操作系统，采用微内核设计思想，内核仅保留最核心的调度、内存、安全原语，所有业务功能都以TA的形式运行在用户态，保证最小信任基，降低安全风险。

1.1 软件分层架构：内核态与用户态严格隔离

OP-TEE严格遵循ARM特权级划分，内核运行在Secure EL1，所有TA应用运行在Secure EL0，通过系统调用完成内核服务请求，从硬件层面实现了内核与应用的权限隔离。整体从上到下分为四层：

层级	特权级	核心组件	职责说明
TA用户层	Secure EL0	可信应用（TA）、静态TA	执行业务逻辑，如加密运算、密钥存储、生物特征比对，只能通过系统调用访问内核资源
系统服务层	Secure EL1	TA管理、会话管理、加密服务、安全存储、时间服务	封装核心安全能力，向TA提供符合GP标准的内部API
内核核心层	Secure EL1	线程管理、内存管理、中断处理、异常处理、SMC交互	操作系统核心能力，管理硬件资源，提供基础运行环境
硬件驱动层	Secure EL1	UART、GIC、TZASC、硬件加密引擎、eFuse	对接安全外设，向上提供统一驱动接口

这种微内核分层设计的安全意义非常明确：内核代码量极小、攻击面小、易于审计；TA运行在最低特权级，即使单个TA被攻破，也无法直接访问内核和其他TA的资源，攻击影响被严格限制在单个TA范围内。

1.2 冷启动全流程：从BL31跳转到内核就绪

OP-TEE由ATF的opteed分发驱动启动，完整启动流程从BL31跳转开始，到内核进入空闲等待SMC结束，每一步都对应你启动日志中的关键输出。

阶段1：汇编入口与最小环境搭建

OP-TEE的汇编入口定义在core/arch/arm/kernel/entry_a64.S，BL31跳转后首先执行这里的代码，完成三件事：

FUNC _start , : /* * Temporary copy of boot argument registers, will be passed to * boot_save_args() further down. */ mov x19, x0 mov x20, x1 mov x21, x2 mov x22, x3 adr x0, reset_vect_table msr vbar_el1, x0 isb #ifdef CFG_PAN init_pan #endif set_sctlr_el1 isb #ifdef CFG_WITH_PAGER /* * Move init code into correct location and move hashes to a * temporary safe location until the heap is initialized. * * The binary is built as: * [Pager code, rodata and data] : In correct location * [Init code and rodata] : Should be copied to __init_start * [struct boot_embdata + data] : Should be saved before * initializing pager, first uint32_t tells the length of the data */ adr x0, __init_start /* dst */ adr x1, __data_end /* src */ adr x2, __init_end sub x2, x2, x0 /* init len */ ldr w4, [x1, x2] /* length of hashes etc */ add x2, x2, x4 /* length of init and hashes etc */ /* Copy backwards (as memmove) in case we're overlapping */ add x0, x0, x2 /* __init_start + len */ add x1, x1, x2 /* __data_end + len */ adr_l x3, boot_cached_mem_end str x0, [x3] adr x2, __init_start

异常向量表配置：设置VBAR_EL1寄存器，指向Secure EL1的异常向量表，定义同步异常、中断、系统错误的处理入口。
CPU状态初始化：配置系统控制寄存器SCTLR_EL1，开启缓存、对齐检查，关闭非安全访问权限。
临时栈设置：设置初始栈指针，为后续C语言执行准备环境。

环境搭建完成后，跳转到C语言主入口函数boot_init()，开始内核初始化。

阶段2：内核核心组件初始化

// 汇编 entry_a64.S 中依次调用这四个函数 boot_init_primary_early(); // 早期硬件初始化 boot_init_primary_late(); // 内核核心子系统初始化 boot_init_primary_runtime(); // 系统服务初始化 boot_init_primary_final(); // 应用加载与启动收尾

按照「硬件→内核→服务→应用」的顺序依次初始化：

控制台初始化：最先初始化串口驱动，输出版本号与启动日志，你看到的OP-TEE version: xxx就是在这里打印的。
MMU与内存初始化：初始化页表，开启MMU，建立内核虚拟地址空间，完成安全内存的区域划分。
中断控制器初始化：配置GIC安全中断分组，注册中断处理函数，建立安全中断响应机制。
线程池初始化：分配静态线程控制块，初始化线程栈，建立线程管理框架。
加密框架初始化：初始化加密算法抽象层，注册软件加密引擎，有硬件加密引擎的平台在此处完成硬件驱动初始化。
系统服务初始化：依次初始化TA管理、会话管理、安全存储、时间服务等核心服务。
静态TA加载：编译进内核的静态TA在此阶段完成注册，无需动态加载即可直接调用。

阶段3：进入空闲等待状态

所有初始化完成后，内核不会主动退出，而是进入空闲循环，等待来自非安全世界的SMC调用。每收到一次SMC请求，就分配一个线程处理对应的TA调用或系统服务，处理完成后返回结果，重新回到空闲状态。

对应启动日志里的细节：INFO: BL31: Initializing BL32 是BL31启动OP-TEE的标志；后续没有直接打印OP-TEE启动日志，是因为QEMU环境默认日志级别配置，开启DEBUG模式后会看到完整的内核初始化输出。

1.3 安全内存布局：硬件边界下的地址空间划分

OP-TEE的所有运行内存都来自TZASC划分的安全物理内存，大小在编译时固定，无法动态扩容——这是安全世界和普通世界最显著的区别之一，也是TEE开发必须关注资源约束的原因。

以你QEMU环境的配置为例，安全物理内存范围为0xe1000000 ~ 0xe1ffffff（共16MB），开启MMU后，虚拟地址空间分为两部分：

1.内核空间（高地址，TTBR1_EL1映射）

所有线程、所有TA共享同一份内核页表，全局唯一；
包含内核代码段（只读、可执行）、内核数据段（读写、不可执行）、内核堆、中断向量表；
仅Secure EL1可访问，TA用户态（Secure EL0）完全无法访问，从硬件页表层面保证了内核安全。

2.用户空间（低地址，TTBR0_EL1映射）

每个TA拥有独立的用户态页表，切换TA时同步更换TTBR0_EL1基地址与ASID地址空间编号；
包含TA的代码段、数据段、栈、堆、共享内存映射区；
仅当前TA可访问，其他TA和内核都不能直接访问TA用户空间的数据。

这种两级页表设计，是OP-TEE实现TA间隔离、内核与用户态隔离的核心软件机制，再配合TZASC的硬件级安全内存隔离，形成了双重防护体系。

1.4 与ATF的交互：两类SMC调用

OP-TEE运行在Secure EL1，不能直接处理来自非安全世界的SMC请求，所有调用都必须经过BL31的opteed分发驱动转发。根据SMCCC规范，OP-TEE支持两类SMC调用，适用场景完全不同：

快速调用（Fast SMC）

特点：关中断执行，耗时极短，不允许挂起，不占用线程资源；
适用场景：简单的系统信息查询、寄存器配置、状态控制，比如获取版本号、设置安全属性；
处理流程：SMC进入EL3→opteed转发→OP-TEE快速处理→直接返回REE，全程不涉及线程上下文切换。

标准调用（Yielding SMC）

特点：开中断执行，允许被外部中断打断，支持挂起和恢复，占用一个线程资源；
适用场景：所有TA调用、复杂加密运算、需要RPC交互的操作；
处理流程：SMC进入EL3→opteed转发→OP-TEE分配线程→执行业务→触发RPC时挂起线程返回REE→REE处理完RPC后重新切入→恢复线程继续执行→调用完成后释放线程。

你日常使用的TA会话调用，全部属于标准调用，依赖线程上下文的挂起与恢复机制；快速调用一般用于内核级控制指令，业务开发很少直接接触。

1.5 镜像格式解析：pager模式与legacy模式的本质区别

这里专门解答你之前遇到的警告：Invalid OPTEE header, set legacy mode。这个警告完全不影响功能，但背后对应OP-TEE两种镜像加载模式的设计差异。

标准v2分页镜像格式

OP-TEE标准的分页镜像由三部分组成，对应编译输出的三个文件：

tee-header_v2.bin：镜像头部，包含魔数、版本、各分区地址与大小信息，标准魔数为0x4554504f（ASCII码"OPTE"）；
tee-pager_v2.bin：分页管理核心代码，常驻内存，负责按需加载分页内容；
tee-pageable_v2.bin：可分页的内核代码与数据，按需加载到内存，节省常驻内存占用。

BL2加载OP-TEE时，会先读取头部解析结构，再把各分区加载到对应地址，支持按需分页模式，减小安全内存的常驻占用。

为什么会出现legacy模式警告

你当前直接使用tee-pager_v2.bin作为BL32镜像传入ATF，BL2读取镜像开头的魔数时，读到的是pager代码段的内容（即你日志中的0xaa0003f3），和标准头部魔数不匹配，因此判定为无效头部，自动降级为legacy模式：

不再解析分区结构，把整个文件当作一个完整的纯二进制镜像；
直接加载到指定的起始地址，不支持按需分页，全部内容常驻内存；
功能完全不受影响，只是内存占用会略大于分页模式。

消除警告的方法

使用完整的标准镜像组合打包FIP，或者直接使用不分页的tee.bin作为BL32镜像，BL2就能正确识别头部，不会出现legacy模式提示。对于调试学习场景，legacy模式完全够用，不需要额外处理。

NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.10.0 (debug):v2.10.0-dirty NOTICE: BL1: Built : 15:25:45, Jun 22 2026 INFO: BL1: RAM 0xe0ee000 - 0xe0f8000 INFO: BL1: cortex_a57: CPU workaround for erratum 1 was applied WARNING: BL1: cortex_a57: CPU workaround for erratum 826974 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 826977 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 828024 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 829520 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 833471 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 859972 was missing! WARNING: BL1: cortex_a57: CPU workaround for erratum 1319537 was missing! INFO: BL1: cortex_a57: CPU workaround for CVE 2017_5715 was applied INFO: BL1: cortex_a57: CPU workaround for CVE 2018_3639 was applied INFO: BL1: cortex_a57: CPU workaround for CVE 2022_23960 was applied INFO: Using crypto library 'mbed TLS' INFO: BL1: Loading BL2 INFO: Loading image id=6 at address 0xe06b000 INFO: Image id=6 loaded: 0xe06b000 - 0xe06b4b6 INFO: Loading image id=1 at address 0xe06b000 INFO: Image id=1 loaded: 0xe06b000 - 0xe07f5d9 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0xe06b000 INFO: SPSR = 0x3c5 NOTICE: BL2: v2.10.0 (debug):v2.10.0-dirty NOTICE: BL2: Built : 15:25:47, Jun 22 2026 INFO: Using crypto library 'mbed TLS' INFO: BL2: Doing platform setup INFO: BL2: Loading image id 3 INFO: Loading image id=7 at address 0xe0a0000 INFO: Image id=7 loaded: 0xe0a0000 - 0xe0a060e INFO: Loading image id=9 at address 0xe0a0000 INFO: Image id=9 loaded: 0xe0a0000 - 0xe0a04da INFO: Loading image id=13 at address 0xe0a0000 INFO: Image id=13 loaded: 0xe0a0000 - 0xe0a0430 INFO: Loading image id=3 at address 0xe0a0000 INFO: Image id=3 loaded: 0xe0a0000 - 0xe0b00c4 INFO: BL2: Loading image id 4 INFO: Loading image id=10 at address 0xe100000 INFO: Image id=10 loaded: 0xe100000 - 0xe1004e8 INFO: Loading image id=14 at address 0xe100000 INFO: Image id=14 loaded: 0xe100000 - 0xe1004ce INFO: Loading image id=4 at address 0xe100000 INFO: Image id=4 loaded: 0xe100000 - 0xe17b238 INFO: OPTEE ep=0xe100000 INFO: OPTEE header info: INFO: magic=0xaa0003f3 INFO: version=0xf4 INFO: arch=0x3 INFO: flags=0xaa01 INFO: nb_images=0xaa0203f5 INFO: Invalid OPTEE header, set legacy mode. INFO: BL2: Skip loading image id 21 INFO: BL2: Skip loading image id 22 INFO: BL2: Loading image id 5 INFO: Loading image id=11 at address 0x60000000 INFO: Image id=11 loaded: 0x60000000 - 0x600004ea INFO: Loading image id=15 at address 0x60000000 INFO: Image id=15 loaded: 0x60000000 - 0x60000440 INFO: Loading image id=5 at address 0x60000000 INFO: Image id=5 loaded: 0x60000000 - 0x60170308 NOTICE: BL1: Booting BL31 INFO: Entry point address = 0xe0a0000 INFO: SPSR = 0x3cd NOTICE: BL31: v2.10.0 (debug):v2.10.0-dirty NOTICE: BL31: Built : 15:25:50, Jun 22 2026 NOTICE: SCR_EL3 value = 0x568 NOTICE: NS bit = 0 (0=Secure, 1=Non-secure) NOTICE: FIQ bit = 1 NOTICE: IRQ bit = 0 INFO: ARM GICv2 driver initialized INFO: BL31: Initializing runtime services INFO: BL31: cortex_a57: CPU workaround for erratum 1 was applied WARNING: BL31: cortex_a57: CPU workaround for erratum 826974 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 826977 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 828024 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 829520 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 833471 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 859972 was missing! WARNING: BL31: cortex_a57: CPU workaround for erratum 1319537 was missing! INFO: BL31: cortex_a57: CPU workaround for CVE 2017_5715 was applied INFO: BL31: cortex_a57: CPU workaround for CVE 2018_3639 was applied INFO: BL31: cortex_a57: CPU workaround for CVE 2022_23960 was applied INFO: BL31: Initializing BL32 INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x60000000 INFO: SPSR = 0x3c5 Bloblist at 0 not found (err=-2) alloc space exhausted ptr 400 limit 0 Bloblist at 0 not found (err=-2) U-Boot 2026.07-rc4-00061-ga7830e87555a (Jun 22 2026 - 15:25:21 +0800) DRAM: 1 GiB using memory 0x7e64e000-0x7f68e000 for malloc() Core: 51 devices, 14 uclasses, devicetree: board Flash: 32 MiB Loading Environment from Flash... *** Warning - bad CRC, using default environment In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole No USB controllers found Net: eth0: virtio-net#32 Hit any key to stop autoboot: 0 => <INTERRUPT> => poweroff

二、线程模型与执行上下文

很多人会下意识地用Linux线程模型来理解OP-TEE，但两者的设计逻辑完全不同：OP-TEE内核本身不实现主动调度器，没有时间片轮转，所有可信线程都与REE侧的Linux线程一一绑定，由Linux内核负责调度。这种设计极大简化了安全世界的内核逻辑，减小了攻击面，同时天然兼容普通世界的调度模型。

2.1 绑定式线程设计：一一对应的执行上下文

OP-TEE采用「调用绑定」的线程模型，核心规则非常明确：

内核在启动时静态分配固定数量的线程，数量由编译宏CFG_NUM_THREADS控制，默认值为8，线程总数不会动态增减；
每个来自REE侧的调用请求，会分配一个空闲线程与之绑定，调用全程独占该线程；
调用结束后，线程释放回空闲池，等待下一次分配；
内核没有调度器，不会主动切换线程，线程的执行和暂停完全由REE侧的调用驱动。

官方文档对此有明确说明：Optee_os does not implement any thread scheduling. Each trusted thread is expected to track a service that is invoked from the normal world。简单说：TEE侧的线程什么时候运行、什么时候暂停，完全由Linux内核调度普通世界线程的节奏决定，TEE只负责保存和恢复上下文。

每个线程对应一个thread_ctx结构体（定义在core/kernel/thread_private.h），包含完整的上下文信息：

寄存器快照：通用寄存器、程序状态寄存器、栈指针，用于挂起和恢复；
线程状态：空闲、运行中、挂起三种状态；
栈地址：内核栈和用户栈的起止地址；
RPC参数：挂起RPC调用时保存的参数与返回值；
互斥锁列表：线程持有的锁，用于异常退出时的资源回收。

2.2 线程状态机与转换流程

所有线程都遵循严格的状态转换规则，整个生命周期只有三种核心状态：

FREE（空闲态）：线程未被分配，处于空闲池中，可被新的调用请求占用。
ACTIVE（运行态）：线程正在执行，占用CPU，处理调用逻辑。
SUSPENDED（挂起态）：线程因触发RPC或外部中断被暂停，上下文被保存，等待REE侧返回后恢复执行。

典型的状态转换流程（一次TA调用）

REE侧发起SMC调用，BL31转发到OP-TEE；
内核从空闲池分配一个FREE线程，将其置为ACTIVE；
加载TA上下文，执行TA调用逻辑；
如果TA触发RPC请求（比如读取文件、获取时间），线程置为SUSPENDED，保存所有寄存器，返回REE处理RPC；
REE处理完RPC后再次发起SMC，内核找到对应挂起线程，恢复上下文，置为ACTIVE，继续执行；
TA调用完成，线程清理资源，置为FREE，放回空闲池。

这种被动式的线程模型，非常适合TEE的业务场景：安全世界的所有操作都是由普通世界触发的请求-响应模式，没有后台任务，不需要主动调度，既简化了内核设计，也降低了安全风险。

2.3 上下文切换：地址空间与寄存器的双重切换

OP-TEE的上下文切换分为两个层面：线程上下文切换和TA地址空间切换，两者互相配合，保证执行的正确性与隔离性。

线程寄存器上下文切换

线程挂起和恢复时，会完整保存/恢复所有通用寄存器、程序状态寄存器、栈指针，保证恢复后能精确回到挂起前的执行状态，和异常切换的上下文保存机制一致。由于线程是静态分配的，每个线程都有独立的内核栈，切换时只需要修改栈指针和恢复寄存器，开销非常小。

TA地址空间切换

如果前后两个线程运行的是不同的TA，切换时还会更换用户态页表：

写入TTBR0_EL1寄存器，指向新TA的用户态页表基地址；
更新CONTEXTIDR_EL1寄存器，设置新的ASID地址空间编号；
执行指令同步屏障，刷新TLB缓存，保证地址映射生效。

通过更换页表基地址和ASID，实现了不同TA之间地址空间的完全隔离——即使两个TA的虚拟地址完全相同，映射的物理内存也完全不同，不会互相访问到对方的数据。源码中该逻辑由core_mmu_set_user_map()函数实现，位于core/arch/arm/mm/core_mmu.c。

2.4 中断处理：两类中断的不同处理逻辑

OP-TEE运行过程中会遇到两类中断，处理方式完全不同：

外部中断（Foreign Interrupt）：来自非安全世界的中断，比如普通外设的IRQ。这类中断发生时，OP-TEE会立即暂停当前线程，保存上下文，通过SMC切回非安全世界，由Linux内核处理中断；等中断处理完成、Linux线程重新切入TEE时，再恢复线程继续执行。这种设计保证了普通世界的中断响应延迟，也避免了安全世界处理非安全中断的安全风险。
本地安全中断（Native Interrupt）：安全外设触发的中断，比如硬件加密引擎完成中断、安全定时器中断。这类中断由OP-TEE内核直接处理，不会切出安全世界，处理完成后回到被打断的线程继续执行。