读懂 NVIDIA Jetson OP-TEE 官方源码：从目录结构到 JetPack / Yocto 构建与运行的完整指南

原创 于 2025-12-15 19:39:11 发布 · 682 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库 #java #redis #YOLO #人工智能

王者杯·14天创作挑战营·第8期 10w+人浏览 490人参与

📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

读懂 NVIDIA Jetson OP-TEE 官方源码：从目录结构到 JetPack / Yocto 构建与运行的完整指南

本文以 NVIDIA 官方 nvidia-jetson-optee-source/optee 源码为核心，从目录结构 → 构建流程 → 产物形态 → 系统集成 → 运行与验证五个维度，系统讲清楚 Jetson 平台上 OP-TEE 的完整工程链路。内容同时覆盖 JetPack（L4T/Ubuntu） 与 Yocto（meta-tegra） 两种主流体系，帮助你在两套系统中都能正确编译、部署并运行 OP-TEE 相关组件。

一、整体架构速览：Jetson 上的 OP-TEE 是如何工作的

在 Jetson 平台，OP-TEE 并不是一个“单独的程序”，而是一整套**跨启动链、跨世界（Secure/Normal）**的工程体系，主要由以下部分组成：

  • OP-TEE OS（Secure World）：运行在 TrustZone Secure World 的可信操作系统
  • TEE Client（Normal World）：Linux 用户态与 Secure World 通信的标准接口库
  • TEE Supplicant（Normal World 守护进程）：辅助 OP-TEE OS 完成存储、文件、RPMB 等操作
  • TA / PTA（Secure World 应用）：在 Secure World 中执行的可信应用
  • CA（Normal World 客户端）：Linux 用户态程序，通过 TEE Client API 调用 TA/PTA

在 Jetson 启动链中：

  1. BootROM / MB1 / MB2 完成早期启动
  2. OP-TEE OS（tos-optee.img）* 被加载到 Secure World
  3. Linux Kernel 启动（Normal World）
  4. Linux 用户空间启动 tee-supplicant
  5. 用户程序（CA）通过 /dev/tee* 与 OP-TEE 通信

二、源码目录总览（以 nvidia-jetson-optee-source/optee 为准）

你当前看到的目录结构如下：

optee/
├── atf_and_optee_README.txt
├── optee_client/
├── optee_os/
├── optee_test/
├── samples/
└── tegra234-optee.dts

这是 Jetson 官方 OP-TEE 源码的完整工程形态，下面逐一拆解。

三、optee_os：Secure World 的核心（最关键）

1. 目录定位

optee_os/
├── core/
├── ldelf/
├── lib/
├── ta/
├── mk/
├── scripts/
├── keys/
└── prebuilt/

optee_os 是运行在 Secure World 的 OP-TEE 操作系统本体，最终会被编译成：

  • tos-optee_t234.img（或同类名称）

并在启动时由 Bootloader 加载。

2. 关键子目录说明

（1）core/
  • OP-TEE 内核核心代码
  • 包含线程调度、内存管理、TEE syscall 实现
  • 与 Linux Kernel 类似的“内核态”部分
（2）ldelf/
  • TA Loader（ELF 装载器）
  • Secure World 中负责加载 .ta 文件
  • xtest / hwkey-agent 中大量日志都与 ldelf 有关
（3）ta/
  • Secure World 中 TA / PTA 的公共支持代码
  • PTA（Pseudo TA）通常以内建形式存在于 OP-TEE OS
（4）mk/
  • 构建系统核心（Makefile 片段）
  • ta_dev_kit.mk 就在这里
  • 所有 TA 的交叉编译都依赖这一套工具链定义
（5）keys/
  • 测试密钥 / 示例密钥
  • 量产中通常不会直接使用这里的 key

3. 构建 optee_os（生成 Secure OS 镜像）

JetPack（L4T）方式

在 NVIDIA 提供的 Driver Package 中：

cd Linux_for_Tegra/source/optee
make PLATFORM=tegra234

生成的核心产物包括：

  • out/arm-plat-tegra/core/tee.bin
  • 经过签名/封装后成为 tos-optee_t234.img

该镜像在刷机阶段写入 A_secure-os 分区。

Yocto（meta-tegra）方式

在 Yocto 中：

  • recipe：optee-os_%.bb
  • include：optee-l4t.inc

Yocto 会：

  1. 拉取 nvidia-jetson-optee-source
  2. 进入 optee_os/
  3. 使用交叉工具链构建
  4. 生成 tos-optee*.img
  5. 集成进最终刷机镜像

关键点：Yocto 构建的 OP-TEE OS 与 JetPack 使用的是同一套源码，只是构建系统不同。

四、optee_client：Normal World 的通信桥梁

1. 目录定位

optee_client/
├── libteec/
├── tee-supplicant/
├── Makefile
└── README.md

optee_client 提供了 GlobalPlatform 标准定义的 TEE Client API。

2. 核心组件

libteec

  • libteec.so

  • CA（Normal World 程序）必须链接的库

  • 提供：

    • TEEC_InitializeContext
    • TEEC_OpenSession
    • TEEC_InvokeCommand
tee-supplicant

  • Linux 用户态守护进程

  • OP-TEE OS 在 Secure World 中无法直接访问 Linux 文件系统

  • 通过 RPC 请求，由 tee-supplicant 代为完成：

    • 文件访问
    • RPMB
    • 安全存储

3. 构建与部署

JetPack
  • NVIDIA 已预编译
  • 默认安装在：
/usr/lib/libteec.so
/usr/sbin/tee-supplicant
Yocto
  • recipe：optee-client_%.bb
  • 构建后自动进入 rootfs

五、optee_test：验证 OP-TEE 是否正常工作的标准套件

1. 目录结构

optee_test/
├── host/
├── ta/
└── README.md

2. xtest 的意义

  • xtest 是 OP-TEE 官方的回归测试程序

  • 能系统性验证：

    • Secure World 是否在跑
    • TA 是否能加载
    • 基本加密算法是否可用

你之前成功运行 xtest，已经证明：

OP-TEE OS + optee_client + tee-supplicant 整条链路是通的

六、samples：官方给你的“工程级示例”

1. 目录结构

samples/
├── hwkey-agent/
├── luks-srv/
├── ftpm-helper/
├── cpubl-payload-dec/
└── pkcs11-sample/

这些不是玩具示例，而是真实业务模型的参考实现。

2. hwkey-agent（与你当前工作最相关）

samples/hwkey-agent/
├── ta/      # Secure World TA
├── host/    # Normal World CA
└── README
  • TA：运行在 Secure World
  • CA：Linux 用户态程序（你已经在 Yocto 中构建并运行）

nvhwkey-app 就来自这里。

3. 构建方式（以 Yocto 为例）

Yocto 中：

  • recipe：optee-nvsamples
  • 构建产物路径示例：
build/ca/hwkey-agent/nvhwkey-app
build/ta/hwkey-agent/*.ta

这些文件在 rootfs 中的放置规则：

文件位置
CA/usr/bin/
TA/lib/optee_armtz/

七、关键文件最终都放到哪里？（非常重要）

类型文件位置
Secure OStos-optee_t234.imgA_secure-os 分区
EKBeks_t234.imgA_eks 分区
TA*.ta/lib/optee_armtz/
CA可执行文件/usr/bin/
libteeclibteec.so/usr/lib/
supplicanttee-supplicant/usr/sbin/

八、JetPack 与 Yocto 的差异总结

维度JetPackYocto
构建方式NVIDIA 预编译 + 手动bitbake 自动
灵活性中高
适合阶段验证 / Demo产品化
OP-TEE 修改麻烦非常自然

你现在走 Yocto 路线，是做安全产品的正确选择。

九、如何基于这套源码继续你的 HelloWorld 安全工程

在你已经完成的阶段基础上：

  1. gen_ekb.py → 把 hello_seed 放进 EKB
  2. OP-TEE OS 启动 → Secure World 解析 EKB
  3. PTA → 从 EKB 读取 seed
  4. CA → 请求“加密/解密服务”，但永远拿不到 key

你现在理解的这套 目录结构 + 构建方式，正是你后续每一步安全设计的“地图”。

九、EKB（Encrypted Key Blob）：Jetson OP-TEE 的密钥构建与运行时使用核心

在前面的章节中，我们已经完整走通了 OP-TEE 的源码结构、构建方式以及在 JetPack / Yocto 中的运行形态。但如果要真正把 OP-TEE 用于业务级安全，就绕不开一个核心机制：EKB（Encrypted Key Blob）。

这一节将把 EKB 的构建逻辑、生成流程、启动时解析路径以及运行时使用方式系统性地补齐，使整篇文章形成一个从“源码 → 构建 → 启动 → 业务”的完整闭环。

在这里插入图片描述

9.1 为什么需要 EKB？

在 Jetson 的安全设计中，有一个非常明确的目标：

业务密钥不能明文存在于 Linux 文件系统中，也不能在运行时被 Linux 直接读取。

但与此同时：

  • OP-TEE 需要在启动后稳定地拿到这些密钥
  • 密钥需要支持 OTA 更新
  • 不同安全业务（磁盘加密、UEFI、应用加密）需要不同 key

EKB 正是为了解决这一组矛盾而设计的：

  • EKB 是一个加密后的二进制密钥容器
  • 存放在 EKS 分区
  • 只能被 Secure World（OP-TEE） 解密和解析
  • Linux 永远只能看到密文

9.2 EKB 在启动链中的位置

在 Jetson 平台，EKB 的使用路径是固定的：

Flash / OTA
   ↓
EKS 分区（eks_t234.img）
   ↓
MB2
   ↓
OP-TEE OS 启动
   ↓
jetson-user-key PTA 解析 EKB
   ↓
密钥进入 Secure World 内存

几个关键点：

  • EKB 不在 rootfs 中
  • EKB 不在 Linux 视角可读的分区中
  • 只有 OP-TEE 在启动早期才能拿到它

9.3 EKB 的核心构建流程（工程视角）

9.3.1 构建输入材料

一个最小但完整的 EKB，至少包含：

输入作用
OEM_K1Root of Trust，烧录到 Fuse
FV随机向量，用于派生 EKB_RK
用户密钥（如 hello_seed）业务真正使用的 seed

这些输入不会直接以明文形式出现在设备上。

9.3.2 gen_ekb.py 的角色

在 nvidia-jetson-optee-source 中，EKB 是通过官方工具生成的：

optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py

这个脚本本质上做了 5 件事：

  1. 使用 OEM_K1 + FV 派生 EKB_RK

  2. 基于 NIST-SP-800-108 KDF 派生：

    • EKB_EK（加密）
    • EKB_AK（认证）

  3. 将用户密钥（如 hello_seed）按 tag 编码进 EKB 内容

  4. 使用 EKB_EK 对内容加密

  5. 使用 EKB_AK 生成 MAC

最终输出：

eks_t234.img

9.4 一个最小业务 EKB 的示例（HelloWorld 场景）

以最简单的业务为例：

我希望 Secure World 中持有一个 hello_seed，用它派生 AES key，对 Linux 文件进行加解密。

构建步骤概览：
  1. 生成 hello_seed（32 字节随机数）
  2. 修改 gen_ekb.py，增加 -in_hello_seed
  3. 将 hello_seed 作为一个新的 key_tag 写入 EKB
  4. 生成 eks_t234.img
  5. 刷写到 A_eks 分区

在这个过程中：

  • hello_seed 只在 生成阶段短暂存在
  • 上板后设备中不再存在明文 seed

9.5 OP-TEE 启动时如何解析 EKB

在 OP-TEE OS 启动过程中：

  1. Secure Engine 从 Fuse 中加载 OEM_K1
  2. OP-TEE 计算 EKB_RK
  3. 验证 EKB 的 MAC
  4. 解密 EKB 内容
  5. 将 key_tag → key 的映射保存到 PTA 内部结构

这一逻辑主要位于：

optee_os/core/pta/jetson-user-key/

这也是为什么：

  • Linux 永远无法直接访问这些 key
  • CA 只能“请求服务”，而不能“请求密钥”

9.6 EKB 与 PTA / CA 的职责边界

组件能看到什么
Linux CA看不到任何明文 key
tee-supplicant看不到 key
PTA（Secure World）能看到并使用 key
OP-TEE Core负责生命周期与隔离

一个典型业务调用是：

Linux CA → PTA：请帮我加密这个 buffer
PTA：使用 EKB 中的 hello_seed 派生 key
PTA：完成加密，返回密文

Linux 全程：

  • 不知道 key
  • 不知道派生方式
  • 只能看到结果

9.7 为什么 EKB 是“一次构建，多次使用”的机制

EKB 有几个重要特性：

  • 不能在运行时修改
  • 只能通过 OTA / 刷机更新
  • 启动后，key 常驻 Secure World 内存

这意味着：

  • 构建 EKB 是安全工程的“源头设计”
  • 后续所有安全业务，都是围绕这个源头展开

十、结语：从源码理解，到安全能力落地

通过补齐 EKB 这一章，可以看到：

  • OP-TEE 并不是一个“黑盒安全模块”
  • EKB 不是魔法，而是可推导、可验证、可工程化的机制

当你理解了：

  • OP-TEE 源码结构
  • JetPack / Yocto 构建路径
  • EKB 的构建与解析

你实际上已经具备了：

在 Jetson 平台上设计、实现并交付安全业务的能力

无论是文件保护、模型加密，还是 OTA / 设备身份，这套链路都已经在你手中。

📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

jetson-inference: 在NVIDIA Jetson上部署深度学习推理网络的指南
m0_56734068的博客
10-17 1693
jetson-inference项目的主要目标是为开发者提供一个易于使用的深度学习推理框架,特别针对NVIDIA Jetson系列设备进行了优化。图像分类 (imageNet)目标检测 (detectNet)语义分割 (segNet)姿态估计 (poseNet)动作识别 (actionNet)除了这些核心功能外,该项目还提供了丰富的示例代码、预训练模型以及详细的文档,方便开发者快速上手和部署自己的应用。
Jetson-AGX-Orin离线安装nvidia-jetpack
Skynet的博客
07-09 1332
2.4、在安装的过程中会有部分安装包报错，提示与已经安装的冲突，可先使用sudo apt-get remove 命令卸载对应的包，再重新执行2.3命令进行安装。2.1、将上述打包好的nvidia-jetpack-archives.tar.gz拷贝到另一台离线的jetson-AGX-Orin上。1.5、安装完成后，使用tar命令打包/var/cache/apt/archives目录下的所有缓存包。2.5、 若在安装的过程有部分包的报错，提示缺少依赖，可用上述步骤1同样的方法打包依赖包来进行安装。
NVIDIA JETSON - Jetson TX2 - E: Unable to locate package python-pip / libgeos-dev
程永强
11-07 3208
NVIDIA JETSON - Jetson TX2 - E: Unable to locate package python-pip / libgeos-dev 1. 异常问题 E: Unable to locate package python-pip strong@ubuntu:~$ sudo apt-get install python-pip Reading package lists... Done Building dependency tree Reading state informati
NVIDIA Jetson & JetPack 全面解析：从硬件到定制镜像
Interview_TC的博客
08-09 1033
摘要： 本文全面解析NVIDIA Jetson嵌入式AI平台，涵盖硬件架构（Tegra SoC集成CPU/GPU）、官方软件栈JetPack SDK（含L4T、CUDA等组件）及主流开发板（Nano/Orin系列）。重点对比JetPack成品镜像与基于Yocto的meta-tegra定制方案，阐明后者在硬件适配和系统裁剪中的优势，并提供定制流程建议（Yocto/Buildroot选型）。文章还列出官方资源入口，帮助开发者根据需求选择从原型开发到量产的适配路径，适用于机器人、工业检测等边缘AI场景。
【Jetson Agx Orin】执行sudo apt install nvidia-jetpack命令时报错：E: Unable to locate package nvidia-jetpack
Black__Jacket的博客
11-07 9875
Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package nvidia-jetpack
【无标题】无法安装 nvidia-jetpack
zzcufo的博客
05-21 1194
orin arm系统安装jetpack
【NVIDIA Jetpack6.0】Jetson AGX Orin内核、设备树更新指南
从善若水的博客
05-12 5296
2024年5月4号，nvidia正式发布了Jetpack6.0版本，这个版本带来了很多功能，包括： - 新的cude、tensorrt等库，可以大幅提升AI推理性能（亲测提升很明显，所以才考虑从Jetpack5.1升级到最新版本）； - 可以使用UpStreaming Linux内核版本，并且提供了实时内核； - 根文件系统升级到了Ubuntu2204；
推荐文章：探索NVIDIA Jetson的无限可能 - OpenEmbedded/Yocto的杰作
gitblog_00984的博客
08-29 709
推荐文章：探索NVIDIA Jetson的无限可能 - OpenEmbedded/Yocto的杰作 项目介绍 在开源世界中，一个闪耀的明星正为NVIDIA Jetson模块提供强大支持——这就是OpenEmbedded/Yocto BSP层专为NVIDIA Jetson设计的版本。伴随着Jetson Linux R36.3.0和JetPack 6.0的强强联合，这款名为meta-tegra的项目，...
如果你还是无法安装 nvidia-jetpack
zzcufo的博客
05-21 1361
Nvidia jstson 安装
记录解决Jetson使用sdkmanger安装jetpack时ssh连接不上的问题以及W: GPG error: file:/var/cuda-repo-l4t-10-2-local：
梁俊星的博客
08-04 2224
解决方法如下
jetson容器：适用于NVIDIA Jetson和JetPack-L4T的机器学习容器
02-03
Jetson和JetPack的机器学习容器 ...要在docker build操作期间启用对CUDA编译器（nvcc）的访问，请在尝试构建容器之前，将"default-runtime": "nvidia"到/etc/docker/daemon.json配置文件中： { " runtimes
nvidia-jetson-llvm-builder:带有OpenMP 4.5卸载支持的Nvidia Jetson Nano（可以扩展到其他Jetson板）的ClangLLVM10编译器的生成器脚本
04-12
带有OpenMP 4.5卸载支持的Nvidia Jetson Nano（可以扩展到其他Jetson板）的Clang / LLVM10编译器的构建器脚本。 该脚本被创建为直接在Nvidia Jetson Nano中执行。 需要更大的SWAP内存，或者我建议您使用AArch64仿真...
jetson-nano-image：为NVIDIA jetson nano板创建自己的图像
01-31
标题 "jetson-nano-image：为NVIDIA jetson nano板创建自己的图像" 指向的是一个项目，目的是教你如何自定义NVIDIA Jetson Nano开发板的操作系统映像。NVIDIA Jetson Nano是一款低功耗、高性能的嵌入式AI开发平台，...
jetson-tx2-pytorch:在Nvidia Jetson TX1TX2上安装PyTorch
05-11
在NVIDIA Jetson TX1 / TX2上安装PyTorch 是一个新的深度学习框架，可以在Jetson TX1和TX2板上很好地运行。 它安装起来相对简单快捷。 与TensorFlow不同，它不需要外部交换分区即可在TX1上构建。 尽管TX2具有足够...
Jetson Nano专用TensorRT8.2.3+ONNX Runtime GPU预编译包：JetPack4.6/YOLOv8/v11环境一键部署工具包
03-20
（1）提供tensorrt-8.2.3.0-cp38-none-linux_aarch64.whl和onnxruntime_gpu-1.16.0-cp38-cp38-linux_aarch64.whl，严格匹配JetPack4.6（CUDA10.2+Python3.8）环境，规避手动编译耗时与依赖冲突问题‌。 （2）支持...
从一次增删改操作开始：彻底理解 MySQL Buffer Pool 的地位与作用
soft2001525的博客
12-11 2028
它是 InnoDB 的核心内存引擎，是所有数据读写的唯一入口，是数据库性能与安全性的关键支撑。理解 Buffer Pool 的逻辑，你就理解了 MySQL 的一半。redo logundo log（事务回滚）MVCC脏页、刷盘策略自适应哈希索引B+树索引加载机制查询优化都与 Buffer Pool 有直接关系。如果你想系统搞懂 MySQL，从 Buffer Pool 开始是最佳路径。如果本篇文章对你有帮助，欢迎：✏️ 评论交流。
Qt6.5.3 mingw64 Ninja编译oracle oci驱动
小蝈蝈的博客
12-12 391
2.将sdk和basic的内容复制到一起，basic中的instantclient_xx_x目录下的内容，sdk的instantclient_xx_xx目录下的内容。├── include/ ← 头文件（来自 sdk/include）到 自己的项目的运行路径下的**/plugins/sqldrivers/**└── sdk/ ← 原始目录（可保留，但非必需）3.将oci.dll生成mingw64支持的.a库。4.切换到Qt源码中的路径下，我的路径。
KingbaseES 面向应用程序的SQL开发：从原理到实战的深度探索
最新发布
优快云博客专家，领域包括但不限于：AI、大数据、Python、架构师，有合作、课程、问题、疑惑请私信博主
12-14 508
KingbaseES数据库SQL开发实践解析 摘要：本文深入探讨国产数据库KingbaseES在SQL开发中的核心实践，重点分析四大关键技术：1) SQL处理机制，包括游标管理和绑定变量优化；2) 正则表达式的高级应用与性能优化；3) 多类型索引的选择与优化策略；4) 事务控制与锁机制。通过具体代码示例，展示了KingbaseES在金融、政务等关键领域的高性能SQL开发能力，包括事务隔离级别设置、死锁检测等高级特性。文章为开发者提供了从基础语法到高级优化的完整SQL开发指南，助力企业实现高效可靠的数据库应用
基于Java+SpringBoot+Vue的美甲店管理系统【附源码+文档+部署视频+讲解)
小熊的博客
12-11 1159
基于SpringBoot的美甲店管理系统开发案例，涵盖用户、美甲师和管理员三大角色功能模块，采用Vue+SpringBoot+MySQL技术栈实现。系统包含服务预约、订单管理、耗材采购等全流程数字化功能，采用MVC设计模式和B/S架构。包含用户、美甲师、管理员三类角色的功能模块，该系统聚焦美甲店的日常运营场景，通过用户端浏览服务与套餐、美甲师端处理预约与评价、管理员端统筹人员、业务与资源的模式，实现美甲店从服务展示、预约调度到耗材管理的全流程数字化，提升门店运营效率与服务体验。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值