高通HLOS与TrustZone通信的框架演进(1): ARM TrustZone通信基石与QSEECOM架构详解

1. 引言：隔离世界之间的通信需求

从事过ARM平台安全开发的工程师对Trustzone应该并不陌生。 ARM TrustZone 技术通过硬件将处理器划分为 Secure World（安全世界） 和 Normal World（非安全世界）。二者在物理上隔离——各自拥有独立的内存地址空间、外设访问权限和执行特权级：

• 内存地址空间（通过 TZASC 等控制器划分）
• 外设访问权限（通过 TZPC 等控制器控制）
• 异常级（Exception Level）执行环境

在高通芯片平台上，Secure World 运行 QTEE（Qualcomm Trusted Execution Environment），其中包含一个微型内核 MINK 和若干 Trusted Application（TA）（如 Keymaster、Widevine DRM、Gatekeeper）。Normal World 运行 HLOS（Linux / Android），需要调用 TA 提供的安全服务，如生成密钥、验证指纹、解密 DRM 内容。

两个世界之间的硬件隔离决定了 HLOS 无法直接调用 TA 的函数，必须依赖一套受控的通信机制，在 Secure Monitor 的仲裁下让请求安全穿越。 高通第一代解决方案就是 QSEECOM。

2. ARMv8 异常级模型与 SMC 指令

理解 QSEECOM 前需要掌握 ARMv8 的异常级模型和世界切换机制：

block-beta
columns 1
block:normal["Normal World"]
block:el0n["EL0"]
ua["User App (HLOS userspace)"]
end
block:el1n["EL1"]
lk["Linux Kernel (HLOS kernel)"]
end
block:el2n["EL2"]
hv["Hypervisor (QHEE)"]
end
end
block:el3["EL3 — Secure Monitor (ARM FW / TZBSP)"]
block:secure["Secure World"]
block:el0s["EL0"]
ta["Trusted Applications (TA)"]
end
block:el1s["EL1"]
qtee["QTEE Kernel (MINK + TZBSP)"]
end
end
end
ua –> lk
lk –> hv
hv –> el3
ta –> qtee
qtee –> el3

ARMv8 异常级与世界划分，参考 [5] ARM Architecture Reference Manual、[4] 80-NH537-4 §2.

两个世界切换的唯一硬件入口是 SMC（Secure Monitor Call）指令。当 HLOS kernel 执行 SMC 时：

QSEECOM 以及后续的 SMCInvoke 都建立在 SMC 之上，区别在于上层封装与抽象层次。

3. QSEECOM 整体架构

QSEECOM 是一套完整的 HLOS ↔ TustZone 通信框架，覆盖从 HLOS 用户态进程到 TrustZone 中 TA 的全链路。

block-beta
columns 1
block:us["HLOS Userspace"]
tca["TA Client\\nApplication"]
lsnr["Listener\\nApplication"]
api["QSEECom API\\n(libQSEEComAPI)"]
end
block:ks["HLOS Kernel"]
drv["QSEECom Driver\\n(/dev/qseecom)"]
end
block:sw["Secure World"]
qtee["QTEE\\n(MINK Kernel + TZBSP)"]
ta2["Trusted Application\\n(TA)"]
end

tca –> drv
lsnr –> drv
api –> drv
drv — "SMC" –> qtee
qtee –> ta2

QSEECOM 端到端架构，参考 [1] 80-PK177-40 §TrustZone、[4] 80-NH537-4 §8.5

核心组件表：

端到端数据流简述：

• HLOS 用户态 Client 调用 libQSEEComAPI 函数
• API 内部通过 ioctl 进入 QSEECom Driver
• Driver 构建 SMC 命令并触发 SMC 指令
• Secure Monitor 跳转到 QTEE
• QTEE 将请求路由到目标 TA
• TA 处理请求，结果写回共享内存
• SMC 返回，HLOS 从共享内存读取结果

4. Client 与 Listener 双角色模型

QSEECOM 定义了两种 HLOS 侧角色：

Client（客户端，主动方）：

• 负责启动（load）一个 TA
• 向 TA 发送命令（SendCommand）
• 接收 TA 的响应
• 关闭（shutdown）TA

Listener（监听器，被动方 / 服务方）：

• 在 HLOS 用户态注册一个监听器
• 阻塞等待 TA 发来的请求
• 处理请求（如文件 I/O、网络访问）
• 将结果返回给 TA

被动等待 TA 请求的一方。当 TA 需要 HLOS 提供某些服务（比如文件 I/O、网络访问）时，TA 会向已注册的 Listener 发送请求，Listener 处理后再将结果返回给 TA。这实现了 TA → HLOS 的反向通信。

sequenceDiagram
participant C as Client
participant T as TA
participant L as Listener

C->>T: Send Command
T–>>C: Response
T->>L: Request to Listener
L–>>T: Response from Listener

QSEECOM Client/Listener 双向通信模型，参考 [4] 80-NH537-4 §8.5

这种双向通信模型解决了 TA 需要 HLOS 服务的场景（例如安全文件系统读写）。但 Listener 需要独立线程阻塞等待，资源开销较大。

5. 通信数据结构与共享内存模型

QSEECOM 的数据交换基于 共享内存（Shared Memory）：

struct qsecom_req {
void *req; // 请求缓冲区指针
uint32_t req_len; // 请求长度
void *rsp; // 响应缓冲区指针
uint32_t rsp_len; // 响应缓冲区大小
};

数据流详细步骤：

大块数据零拷贝： QSEECom_send_modified_cmd 允许传递 ION 文件描述符。HLOS 先通过 ION 分配大块连续物理内存，将 fd 传给 TrustZone，TrustZone 可直接访问同一块物理内存，避免数据拷贝，适用于 DRM 视频帧等场景。

6. 关键 API 清单

Client 侧 API：

int QSEECom_start_app(struct QSEECom_handle **handle,
const char *app_name, uint32_t size);
int QSEECom_shutdown_app(struct QSEECom_handle *handle);
int QSEECom_send_cmd(struct QSEECom_handle *handle,
void *send_buf, uint32_t buf_len,
void *recv_buf, uint32_t rbuf_len);
int QSEECom_send_modified_cmd(struct QSEECom_handle *handle,
void *send_buf, uint32_t buf_len,
void *recv_buf, uint32_t rbuf_len,
struct qsecom_ion_fd_info *ion_fd_info);

Listener 侧 API：

int QSEECom_register_listener(struct QSEECom_handle *handle,
uint32_t listener_id, uint32_t sb_length);
int QSEECom_unregister_listener(struct QSEECom_handle *handle);
int QSEECom_receive_req(struct QSEECom_handle *handle,
void *req_buf, uint32_t req_buf_len);
int QSEECom_send_resp(struct QSEECom_handle *handle,
void *resp_buf, uint32_t resp_buf_len);

7. 典型通信流程（无 Listener）

• 流程一：Client 向 TA 发送命令（无需 Listener）

sequenceDiagram
participant C as HLOS Userspace<br/>(TA Client)
participant D as HLOS Kernel<br/>(QSEECom Driver)
participant T as Secure World<br/>(QTEE + TA)

C->>D: QSEECom_start_app()
D->>T: ioctl → SMC (LOAD_APP)
T–>>T: Load & start TA
T–>>D: return
D–>>C: handle

C->>C: 填充 send_buf
C->>D: QSEECom_send_cmd()
D->>T: ioctl → SMC (SEND_CMD)
T–>>T: TA 处理请求
T–>>D: SMC return
D–>>C: 读取 recv_buf

C->>D: QSEECom_shutdown_app()
D->>T: ioctl → SMC (SHUTDOWN_APP)
T–>>T: Unload TA
T–>>D: return
D–>>C: done

Client→TA 命令发送流程，参考 [4] 80-NH537-4 §8.9 Figure 8-1/8-2

• 流程二：TA 请求 Listener 服务 当 TA 需要访问 HLOS 的资源时（例如安全文件系统的 I/O 操作），可以通过已注册的 Listener 反向请求 HLOS：

sequenceDiagram
participant L as HLOS Userspace<br/>(Listener)
participant D as HLOS Kernel<br/>(QSEECom Driver)
participant T as Secure World<br/>(QTEE + TA)

L->>D: QSEECom_register_listener()
D->>T: ioctl → SMC (REGISTER_LSNR)
T–>>D: return
D–>>L: handle

L->>D: QSEECom_receive_req()
Note over L,D: 阻塞等待 TA 请求…
T->>D: TA 发起请求 (SMC)
D–>>L: 唤醒 Listener，交付请求数据

L->>L: 处理请求，填充响应
L->>D: QSEECom_send_resp()
D->>T: ioctl → SMC (SEND_RESP)
T–>>T: TA 获得结果
T–>>D: return

TA→Listener 反向请求流程，参考 [4] 80-NH537-4 §8.9 Figure 8-3/8-4

8. 小结

QSEECOM 是第一代实用的 HLOS↔TrustZone 通信框架，它基于 SMC + 共享内存 + ION 零拷贝提供了基础能力，并支持 Listener 反向通信。然而，其扁平模型、缺乏类型安全、无身份传递等设计局限，在高版本芯片和高安全需求场景下逐渐暴露，为后续 SMCInvoke 的诞生埋下了技术驱动力。