ARM64 平台安全学习记录

目标：先用书把架构图画出来，用 QEMU 把图对到源码，再切 RK3588 / Jetson。

最终用途：为两平台的 OTA 做铺垫（验签、A/B、回滚、密钥分层）。

原则：前一阶段的「阶段验收」全部勾完，再开下一阶段。芯片 SDK 放到阶段 D。

如何打卡

状态只填：未开始 / 进行中 / 完成 / 跳过
每项「完成」必须同时满足：阅读勾选 + 产出物存在 + 验收题能口头答出
产出物统一放：notes/（本文件同级自建即可）
建议记录：开始日期、完成日期、实际用时（小时）
量化规则：本文件所有 - [ ] 勾完数 / 总数 = 完成率。阶段完成率单独统计。

总进度

阶段	主题	计划	状态	完成率
A	书籍：三张架构图	约 2 周	未开始	0/28
B	QEMU `qemu_v8` 对照	约 2 周	未开始	0/42
C	Linux 侧信任链与 OTA 概念实验	约 1 周	未开始	0/16
D	平台差异：RK3588 / Jetson	阶段 C 之后	锁定	0/20

当前完成率：0 / 106

书目代号

代号	文件
M	`Engineering Secure Devices (Dominik Merli)...pdf`
TZ	`手机安全和可信应用开发指南：TrustZone与OP-TEE技术详解...pdf`
G	`Secure Boot Encryption with Linux...pdf`
Y	`Building_Secure_Firmware_Armoring_the_Foundation_of_the_Platform.pdf`
U	`UEFI Secure Boot Customization...pdf`（阶段 D 才读）

不读（本路径）：Linux Firewalls、Mastering Reverse Engineering。

Practical Reverse Engineering 仅在需要反汇编 ATF/OP-TEE 时作为工具书，不列入打卡。

阶段 A --- 书籍架构（先不出板）

阶段验收（3 张图必须交）：

notes/图1-设备安全与OTA.md：Verified boot / Measured boot / 磁盘加密 / OTA 签名四者区别
notes/图2-ARM64启动与TEE.md：ROM → BL1 → BL2 → BL31 → BL32 → BL33 → Linux，并画出一次 SMC
notes/图3-信任延续与OTA.md：谁验包、写哪一槽、失败回哪、哪些镜像必须一起升

A1 图 1：设备在保什么（M）

M 第 1 章安全开发与资产/威胁
M 第 2 章密码学（签名 vs 加密、哈希、AEAD 够用即可）
M 第 5 章机密存储 / 安全内存
M 第 6 章设备身份
M 第 8 章 Secure Boot 与启动后完整性
M 第 9 章安全固件更新、A/B、防回滚

A1 验收（口头，全过才算完成）：

能说明为什么「内核模块签名」不是 SoC Secure Boot
能说明熔丝公钥哈希烧错为什么不能改
能说明 A/B 解决掉电变砖、签名解决恶意包，两者缺一不可

产出：

notes/图1-设备安全与OTA.md

A2 图 2：TrustZone / TF-A / OP-TEE（TZ）

先读架构，细读源码级章节放到阶段 B 对着 QEMU 读。

暂缓（阶段 B3 再精读）：TZ 11--14。

第一遍跳过：TZ 15--17（线程/syscall/IPC）。

A2 验收：

能画出 EL0/EL1/EL2/EL3 与 Secure / Non-secure 正交
能说明 AArch64 世界切换发生在 EL3，不是 ARMv7 Monitor 模式
能默写：BL31=EL3 常驻，BL32=OP-TEE S-EL1，Linux=EL1-NS
能说明一次 SMC 从 Linux 到 OP-TEE 经过哪些异常级

产出：

notes/图2-ARM64启动与TEE.md

A3 图 3：内核之后的链 + 固件韧性（G + Y）

G 第 2 章 Secure Boot 是什么、不是什么；Chain-of-Trust
G 第 3 章 Rescue vs A/B；工厂灌装 vs 升级
G 第 1 章 Linux Crypto API / keyring / sealed key（可略读实现细节）
G 第 4 章熔丝中心 vs 混合密钥
Y 第 3 章 Firmware Protection
Y 第 4 章 Firmware Detection（Secure Boot 案例）
Y 第 5 章 Firmware Recovery（OTA 失败就是这一章）
Y 第 7 章 Trusted Boot（SRTM vs Secure Boot，知道差别即可）

A3 验收：

能写出 OTA 四问：谁验包 / 写哪槽 / 失败回哪 / 哪些必须一起升
能区分 Verified boot 与 Measured boot
能说明 U-Boot env 全可写为什么会破坏 Secure Boot

产出：

notes/图3-信任延续与OTA.md

阶段 A 关门条件： 三张图都在 notes/ 且 A1--A3 验收全勾。

阶段 B --- QEMU `qemu_v8` 对照清单

环境约定

text 复制代码

工作目录：~/optee-qemu   （可改，改完写在下面）
实际路径：________________
获取：
  repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
  repo sync
  cd build && make -j$(nproc) toolchains && make -j$(nproc)
运行：
  make run-only     # 或当前 build 目录文档写明的 run 目标

repo 同步完成，记录 commit：TF-A ________ / OP-TEE ________ / Linux ________
make run 能进 Linux shell
保存完整启动日志：notes/qemu_v8_boot.log

书中 bios.bin、部分函数名是 2018 年的。以本机树为准，书只对阶段和概念。

B0 日志里先把阶段标出来（对应 TZ 第 6 章）

在 notes/qemu_v8_boot.log 里用注释标出下列行（字符串随版本略变，含义必须对上）：

Booting Trusted Firmware / BL1: → TZ 6.3.1
Loading BL2 / BL1: Booting BL2 → TZ 6.3.2
BL31: 常驻 EL3 → TZ 6.3.3
OP-TEE 横幅（I/TC: 或 OP-TEE）→ TZ 6.3.4 / 第 7 章
BL33（EDK2/U-Boot）加载内核 → TZ 第 5.3
Linux 起来，tee / optee 驱动信息 → TZ 5.5 / 第 9 章
tee-supplicant 起来 → TZ 5.6 / 第 8 章

产出：

notes/qemu_v8_boot.log.annotated.md（每段日志 → 书中章节 → 源码路径）

B1 TF-A 源码对照（TZ 6.3）

在本机 arm-trusted-firmware/（或 trusted-firmware-a/）中打开并写 3 句注释到笔记：

勾选	阶段	书	日志关键词	源码（以本机为准，路径可能微调）	你要写清的 3 句话
-	BL1	TZ 6.3.1	`BL1:` `Loading BL2`	`bl1/bl1_main.c`；平台：`plat/qemu/`	谁调用、验不验下一阶段、跳到哪
-	BL2	TZ 6.3.2	`BL2:`	`bl2/bl2_main.c`	加载 BL31/BL32/BL33、FIP 是什么
-	BL31	TZ 6.3.3	`BL31:`	`bl31/bl31_main.c`	为什么常驻、PSCI/SMC 入口
-	SPD opteed	TZ 6.3.4 / 10.4	`BL32` / OP-TEE 入口	`services/spd/opteed/`	`opteed` 如何把 SMC 转给 OP-TEE
-	PSCI	（内核电源）	次核带来	`services/std_svc/psci/`	和 Linux `psci` 驱动的关系
-	可选 TBB	TZ 6.2.2	`TRUSTED_BOARD_BOOT`	`make` 里 `TF_A_TRUSTED_BOARD_BOOT`	QEMU 上如何打开验签（不做熔丝）

B1 验收：

不看笔记能按顺序说出 5 个 BL 谁加载谁
能指出 SPD=opteed 关掉之后 OP-TEE 为什么起不来

B2 从 OP-TEE 到 Linux（TZ 5、7、8、9）

TZ 第 7 章精读 + 打开 OP-TEE 入口（常见：core/arch/arm/kernel/ 下 generic_entry.c / boot.c，以本机为准）
记录 OP-TEE 平台名：PLATFORM=________________（qemu_v8 多为 vexpress-qemu_armv8a）
Linux：drivers/tee/optee/ 列出本机文件名（smc_abi.c / rpc.c / core.c 等）
Linux：drivers/firmware/psci/
Linux：SMCCC（arch/arm64/kernel/smccc-call.S 或当前等价文件 + include/linux/arm-smccc.h）
guest 内确认：ls /dev/tee0（或 teepriv0）存在
guest 内：xtest 跑通（记录通过/失败条数：________）
guest 内：optee_example_hello_world（或当前 examples 名）跑通

产出：

notes/B2-REE与驱动.md：/dev/tee*、supplicant、xtest 结果截录

B2 验收：

能说明 tee0 与 teepriv0 谁给 CA、谁给 supplicant
能说明 tee_supplicant 死了以后哪些 TA 功能会挂（加载 TA、RPMB、REE FS）

B3 一次完整 SMC（TZ 10--13）

对着一次 hello_world / TEEC_InvokeCommand 填表（写到 notes/B3-SMC调用栈.md）：

CA：TEEC_OpenSession / TEEC_InvokeCommand（optee_client / examples）
libteec 对应 ioctl
内核 optee 驱动发 SMC 的函数名：________________
TF-A opteed handler 函数名：________________
OP-TEE 收 SMC / 找 session / 进 TA 的函数名：________________
共享内存：谁分配、双方怎么映射（TZ 第 14 章可在此开始精读）
TZ 第 11 章：fast SMC vs standard SMC 各举一个本机例子
TZ 第 12 章：日志或代码里指出 IRQ 如何打断 TA（能讲清即可，不要求改代码）
TZ 第 13 章：静态 TA vs 动态 TA，xtest/hello 属于哪一种

B3 验收（阶段 B 关门题）：

从 CA 到 TA 的调用栈能不看笔记讲 8 层以上（用户态 → 驱动 → SMCCC → EL3 → OP-TEE → TA）
假设 Linux 已被 root：指出攻击者仍拿不到的东西（TA 内存 / 安全世界密钥），以及 tee_supplicant RPC 仍可能被滥用的点

B4 本阶段明确不做

已理解并写进笔记：QEMU 不能代替 OTP 烧写、RK3588 rkbin blob、Jetson MB1/PSC、真 RPMB、现场掉电变砖

阶段 B 关门条件： qemu_v8 能进系统、xtest 有记录、B3 调用栈笔记存在、A 的图 2 已用真实日志修订一版。

阶段 C --- Linux 侧信任链与 OTA 概念（仍可在 QEMU）

不依赖 TrustZone。可另起普通 qemu-system-aarch64，或在同一 guest 里做。

对照：G 第 2--3 章、M 第 8 章后半 + 第 9 章。

内核模块签名：编一个未签名模块，确认加载失败（记录 dmesg）
dm-verity 或等价：故意改一块 rootfs，启动失败或只读告警（记下现象）
假 A/B：两个 rootfs 分区 + 启动变量；写非当前槽后切换
故意把新槽写坏，确认能回到旧槽（必须做）
限制启动变量：只允许改槽位，不能塞脚本（对应 G/U-Boot env 讨论）
写 notes/OTA状态机.md：正常升 / 掉电 / 验签失败 / 启动失败四条路径
（可选）keyring / sealed key：G 第 1 章跟做一条
（可选，靠后）QEMU + OVMF：PK/KEK/db 签内核 ------ 仅为以后 Jetson UEFI 预习，RK3588 可跳过

C 验收：

OTA 四问能对着自己的假 A/B 演示，而不是只背定义
能说明「包签名通过但写到当前槽」为什么仍可能变砖

阶段 C 关门条件： notes/OTA状态机.md + 一次成功回滚记录。

阶段 D --- 平台差异（锁定，完成 C 再开）

把 QEMU 模型替换成零件表，不重新学架构。

D0 开门检查

阶段 A 三张图齐全
阶段 B SMC 调用栈笔记齐全
阶段 C 回滚演示做过

D1 差异表（先填空，再开 SDK）

复制到 notes/平台差异表.md 填：

通用模型	RK3588 实际	Jetson 实际	我已核对
ROM + 公钥哈希	BootROM + OTP 中 RSA 公钥 SHA256	BootROM/PSCROM + PKC；可选 SBK	-
BL2	DDR blob + SPL/miniloader	MB1 / MB2	-
BL31	`rk3588_bl31_*.elf` → `trust.img`	TOS 内 ATF	-
BL32	`rk3588_bl32_*.bin` → `trust.img`	`A/B_secure-os`	-
BL33	U-Boot	UEFI	-
内核验签	FIT / `boot.img`	开 SB 后常从 APP `/boot`	-
OTA	RAUC/SWUpdate + 自建 boot 双槽	Capsule + `l4t_generate_ota_package`	-
密钥包	RPMB / OTP 派生	`A/B_eks`（EKB，禁止运行时 dd）	-

D2 RK3588（未熔丝 → 签名链 → 再谈锁 OTP）

打开 SDK：rkbin + RKTRUST/RK3588TRUST.ini，记录 BL31/BL32 文件名与 SEC=
未烧 OTP，打出签名的 idbloader / trust.img / uboot.img / boot.img 并能启动
启动日志按 B0 同一套标签重新标注（名字会变，阶段不能丢）
搞清官方写 OTP 流程；开发机禁止自动 lockdown
rootfs A/B：RAUC 或 SWUpdate，复用阶段 C 状态机
单独设计 trust.img + U-Boot 失败策略（备份槽或 rk 救援）
读 Pengutronix《Secure Boot on Rockchip RK3588》并写 5 条与官方 SDK 的差异

D3 Jetson（未熔丝 → Capsule → UEFI SB → 最后 PKC）

确认模组：Orin Nano / NX / AGX / 其他：________ ；BSP：________
读分区表（如 flash_t234_qspi.xml），标 TOS / EKS / MB1 / UEFI / APP
未熔丝 Capsule：只升 bootloader，确认槽位翻转
ROOTFS_AB 做一次 image-based OTA
打开 UEFI Secure Boot 后再做一次（读 U 报告 PK/KEK/db）
理解 EKB / OEM_K1：只能 OTA 写 EKS
PKC/SBK 熔丝放到最后；锁前必须能用同一密钥重出完整可启动镜像

D4 两平台公共 OTA 策略（本路径终点）

密钥分层：熔丝 RoT / OTA 证书 / 磁盘或 EKB 密钥三套分开
兼容矩阵：TOS/OP-TEE ↔ 内核 ↔ rootfs 哪些必须同包升级
防回滚：旧槽有洞时不能靠改 env/UEFI 变量打回去
工厂锁机检查单：测完 → 烧熔丝 → 用生产密钥包做一次升级演练

阶段 D 关门条件： 差异表填完；至少一侧平台完成「未熔丝 A/B 升级 + 故意失败回滚」。

每日记录（复制行）

日期	阶段	做了什么	用时	卡点	下次第一件事

三张图模板（阶段 A 直接填）

图 1

text 复制代码

资产：________________
攻击者：________________
Verified boot 拦住：________________
Measured boot 记下：________________
磁盘加密挡住：________________
OTA 签名拦住：________________
A/B 解决：________________
防回滚解决：________________

图 2

text 复制代码

EL3  Secure     : TF-A BL31     文件/日志：________
S-EL1 Secure    : OP-TEE BL32   文件/日志：________
EL1  NS         : Linux         文件/日志：________
EL0  NS / S     : CA / TA

SMC: CA -> libteec -> ioctl -> optee.ko -> SMCCC -> opteed -> OP-TEE -> TA
本机函数名：
  ioctl: ________
  SMC:   ________
  EL3:   ________
  TEE:   ________

图 3

text 复制代码

验包密钥：________ （存在：熔丝 / 证书链 / 其他）
写槽：非当前 = ________
切槽原子操作：________
mark-good：谁写 ________ 何时写 ________
必须同包：________ + ________
掉电路径：________
验签失败：________
启动失败：________

修订记录

日期	变更
2026-09-14	初版：书 → QEMU qemu_v8 → RK3588/Jetson；服务 OTA

ARM64 平台安全学习记录