1. OP-TEE概述：TEE概念、OP-TEE架构、OP-TEE与Linux的关系、开发环境搭建

1.1 什么是TEE？—— 从一次“翻车”说起

我记得刚入行做嵌入式安全那会儿，接手一个金融支付终端项目。客户要求把密钥存储在安全区域，我当时想：不就是把密钥藏起来吗？直接写死在Flash里不就行了？结果被安全审计打回来三次。后来我才真正理解——普通世界（Rich OS）里没有真正的秘密。

TEE，全称Trusted Execution Environment，翻译过来叫“可信执行环境”。说白了，它就是在主处理器上划出一块“安全飞地”。这块飞地有自己的内存、自己的外设、自己的操作系统，甚至自己的中断处理。普通世界（比如Linux）完全看不到里面发生了什么。

你可能会问：为什么不用独立的Secure Element（SE）芯片？嗯，SE确实更安全，但成本高、带宽低。TEE的优势在于：它跑在主CPU上，性能好，成本低。我做过一个对比测试，同样做一次RSA-2048签名，TEE比SE快了将近两个数量级。

核心要点：TEE不是硬件隔离，而是基于ARM TrustZone技术的“系统级隔离”。它把SoC硬件和软件资源划分为两个世界：安全世界（Secure World）和普通世界（Normal World）。

1.2 OP-TEE架构——我画的第一张架构图

OP-TEE是Linaro主导的开源TEE实现。我第一次看它的源码时，说实话，有点懵。代码量不小，而且涉及ARM异常等级、Monitor模式、SMC调用这些底层概念。后来我画了一张图，才把整个脉络理清楚。

OP-TEE 整体架构图 普通世界 (Normal World) Linux 用户空间 CA (Client App) libteec (TEE Client API) Linux 内核空间 OP-TEE 驱动 安全世界 (Secure World) OP-TEE OS 内核 TA (Trusted App) 安全存储 密码学服务 Internal API Monitor 模式 (EL3) SMC 异常处理 | 世界切换 | 安全中断管理 SMC调用

这张图我当年画了三个版本才满意。你看，整个架构分三层：

  • 普通世界：跑Linux，CA（Client Application）通过libteec库调用TEE Client API
  • 安全世界：跑OP-TEE OS，TA（Trusted Application）在这里执行敏感操作
  • Monitor模式：EL3异常等级，负责两个世界的切换

我习惯把Monitor模式比作“海关”。普通世界的数据要进入安全世界，必须经过海关检查。这个检查就是SMC（Secure Monitor Call）指令。

1.3 OP-TEE与Linux的关系——不是替代，是互补

很多人刚接触TEE时会问：OP-TEE是不是要取代Linux？

完全不是。我打个比方：Linux是“客厅”，OP-TEE是“保险柜”。你平时在客厅活动、招待客人，但贵重物品要锁在保险柜里。两者各司其职。

具体来说，它们的关系体现在三个层面：

维度 Linux（普通世界） OP-TEE（安全世界）
运行环境 完整的操作系统，支持多进程、网络、文件系统 精简的微内核，只提供安全服务
通信方式 通过OP-TEE驱动发起SMC调用 通过Monitor模式响应SMC请求
内存隔离 无法访问安全内存区域 可以访问普通内存（需显式映射）
典型应用 UI、网络、文件管理 密钥管理、DRM、支付认证

避坑指南：我曾经在一个项目中，把TA的堆栈设得太小，结果TA在处理大块数据时直接崩溃。OP-TEE的TA默认堆栈只有4KB，如果你要处理大缓冲区，记得在manifest文件里调大。具体做法是在ta.manifest中设置stack_size = 8192。

1.4 开发环境搭建——我踩过的坑，你别再踩

搭建OP-TEE开发环境，说难不难，说简单也不简单。我第一次搭环境时，光编译工具链就折腾了两天。现在我把步骤总结一下，你照着做，半小时内应该能跑起来。

1.4.1 硬件要求

  • 一台x86_64的Linux主机（我习惯用Ubuntu 20.04/22.04 LTS）
  • 至少8GB内存，建议16GB
  • 50GB空闲磁盘空间

1.4.2 安装依赖包

sudo apt-get update
sudo apt-get install -y \
    android-tools-adb \
    android-tools-fastboot \
    autoconf \
    automake \
    bc \
    bison \
    build-essential \
    ccache \
    cscope \
    curl \
    device-tree-compiler \
    expect \
    flex \
    ftp-upload \
    gdisk \
    iasl \
    libattr1-dev \
    libcap-dev \
    libfdt-dev \
    libftdi-dev \
    libglib2.0-dev \
    libhidapi-dev \
    libncurses5-dev \
    libpixman-1-dev \
    libssl-dev \
    libtool \
    libusb-1.0-0-dev \
    make \
    mtools \
    netcat \
    python3-cryptography \
    python3-pip \
    python3-pyelftools \
    python3-serial \
    rsync \
    unzip \
    uuid-dev \
    xdg-utils \
    xterm \
    xz-utils \
    zlib1g-dev

1.4.3 克隆repo并编译

OP-TEE官方提供了一个repo manifest，可以一键拉取所有组件：

mkdir op-tee
cd op-tee
repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
repo sync -j4

# 编译
cd build
make toolchains
make -j$(nproc)

注意：repo sync时如果网络不好，可能会失败。我建议你配置一下代理，或者用国内镜像源。另外，make toolchains这一步会下载ARM交叉编译工具链，大概1.5GB，耐心等待。

1.4.4 运行QEMU仿真

编译完成后，直接启动QEMU仿真：

make run-only

你会看到两个终端窗口弹出来：一个是Linux控制台，一个是OP-TEE的安全终端。在Linux终端里输入：

xtest

这个命令会运行OP-TEE的测试套件。如果所有测试都通过，恭喜你，环境搭建成功了！

我的小技巧：每次编译前，先执行make clean再make，虽然慢一点，但能避免很多奇怪的链接错误。另外，我习惯在~/.bashrc里加一行export PATH=$PATH:~/op-tee/build，这样随时可以运行编译命令。

1.5 本章小结

嗯，到这里，OP-TEE的概述部分就讲完了。我们聊了TEE的核心概念，看了OP-TEE的整体架构，理清了它和Linux的关系，最后亲手搭了一套开发环境。这些是后续所有实战内容的基础。

我个人觉得，理解TEE最好的方式就是动手。别光看文档，把环境搭起来，跑几个TA试试。遇到问题很正常，我当年也踩过无数坑。关键是——别怕，慢慢来。

可可精品资料库
← 上一章 📖 返回目录 下一章 →