技术摘要：通过 DSL 引导与 LLM 辅助补丁实现 TEE 分区问题的自动化修复

1. 问题陈述

可信执行环境（TEE）提供基于硬件的隔离，以保护敏感数据和计算免受不受信任操作系统的侵害。然而，TEE 应用程序必须通过软件接口（SDK）与不受信任的操作系统进行交互。“正常侧”（不受信任）与“安全侧”（受信任）之间的分区不当会引入严重漏洞，统称为不良分区问题。这些问题包括：

1. 未加密数据输出：敏感数据（如密钥、令牌）从 TEE 传输到正常侧时未进行加密。
2. 输入验证薄弱：对从正常侧传递的输入检查不足，导致 TEE 内部发生缓冲区溢出或内存损坏。
3. 直接使用共享内存：依赖由不受信任操作系统控制的共享内存区域且缺乏完整性验证，从而允许篡改。

虽然存在静态分析工具来检测这些问题，但由于三个具体挑战，自动化修复在很大程度上仍未被探索：

• 缺乏标准指南：与通用软件安全（如 OWASP）不同，TEE 开发缺乏标准化的安全分区实践，使得难以定义可靠的修复基准。
• 语义提取困难：TEE 应用程序通常用低级 C 语言编写，其中语义信息（如缓冲区大小、有效索引范围）是隐式的或动态的，使得静态工具难以推断正确的修复参数。
• 成熟测试的缺失：TEE 环境限制了调试和监控。大多数项目缺乏单元测试或回归测试套件，且交叉编译要求使得“生成 - 编译 - 测试”循环既昂贵又复杂。

2. 方法论：TEERepair

作者提出了TEERepair，这是一个将用于编码修复规则的特有领域语言（DSL）与用于上下文感知语义合成的大型语言模型（LLM）相结合的框架。工作流程包含六个步骤：

A. DSL 引导的修复模板

为了解决缺乏指南的问题，作者设计了一种 DSL 来形式化地编码安全的 TEE 分区模式。

• 语法：该 DSL 定义了常见 TEE 操作的节点（如 COPY、MALLOC、ENC、HASH）和条件守卫（IF）。
• 修复规则：该 DSL 编码了三种类型的转换规则，分别对应漏洞类别：
  • 规则 1（加密）：用内存分配、加密（ENC）和密文复制的序列替换直接数据复制。
  • 规则 2（验证）：在数据使用前插入条件守卫（IF），以检查缓冲区大小或数组索引是否越界。
  • 规则 3（共享内存）：用深度复制到 TEE 内部缓冲区替换共享内存的浅层复制，随后在使用前进行完整性检查（哈希）。
• 模板：这些 DSL 规则被实例化为包含占位符（如 $cipher、$len）的补丁模板，用于上下文特定的变量。

B. LLM 辅助的占位符合成

为了解决从低级 C 代码中提取语义信息的困难：

• 提示：系统构建包含漏洞代码片段、问题类型以及 DSL 生成的补丁模板的提示。
• 推理：LLM（具体为 gpt-4.1-mini）分析代码上下文以推断占位符的正确值（例如，识别哪个变量代表缓冲区大小，或使用哪个加密密钥）。
• 约束：LLM 被限制为仅填充占位符，而不是从头生成代码，从而降低了语法错误和幻觉的风险。

C. 两阶段验证流水线

为了解决成熟测试的缺失和硬件限制：

1. 阶段 1：静态反馈（修复阶段）：静态分析器（DITING）重新分析补丁代码，以验证漏洞模式是否已被消除。如果问题仍然存在，则向 LLM 提供反馈以进行细化。此过程无需硬件执行。
2. 阶段 2：运行时验证（功能阶段）：一旦静态分析通过，系统便基于 TEE 源代码的入口点和参数自动合成一个测试客户端（正常侧程序）。该客户端在真实 TEE 硬件（如配备 TrustZone 的 Raspberry Pi 3B）上编译并执行，以验证补丁是否编译、运行并产生预期的安全输出（例如，正确的密文、针对无效输入的正确错误代码）。

3. 主要贡献

• TEERepair 框架：首个专门针对 TEE 不良分区问题设计的自动化修复框架，弥合了静态检测与自动化修复之间的差距。
• TEE 安全的 DSL：一种新颖的特有领域语言，将安全分区模式编码为结构化转换，在缺乏标准指南的情况下提供了可靠的基准。
• LLM-DSL 协同：一种混合方法，其中 DSL 提供结构化安全知识，而 LLM 解决低级 C 代码中依赖上下文的语义歧义。
• 自动化测试客户端生成：一种为 TEE 应用程序自动生成测试客户端和验证用例的方法，克服了现有测试套件稀缺的问题。
• 基准与评估：将 TEERepair 应用于PartitioningE-Bench，该基准包含跨多个项目的 89 个真实世界的不良分区案例。

4. 实验结果

作者在 PartitioningE-Bench 上评估了 TEERepair，并将其与基于模板的工具（TBar、Prophet）、基于学习的工具（VulMaster）以及基于 LLM 的工具（ChatRepair、SAN2PATCH）等基线进行了比较。

• 修复成功率：TEERepair 实现了**87.6%**的成功率（89 个漏洞中有 78 个被正确修复）。
  • 未加密数据输出：94.3%（33/35）。
  • 输入验证薄弱：67.0%（20/29）。
  • 直接使用共享内存：100%（25/25）。
• 基线性能：表现第二好的工具 TBar 仅实现了 19.1%（17/89）。其他工具表现显著更差，许多工具甚至无法为共享内存问题生成任何正确的补丁。
• 消融研究：移除 DSL 或 LLM 中的任一部分都会大幅降低性能（仅 DSL：22.5%；仅 LLM：13.4%），证实了两个组件都是必不可少的。
• 真实世界验证：作者将 TEERepair 应用于真实的 GitHub 项目。他们提交了5 个拉取请求，其中2 个得到了项目维护者的确认并合并（在 basicAlg_use 和 PPFL 项目中）。

5. 意义与主张

该论文声称，TEERepair 证明了自动化修复 TEE 应用程序中复杂且安全关键的漏洞的可行性，这一领域此前由于缺乏指南和测试基础设施而被认为对自动化工具来说过于具有挑战性。

• 实际适用性：补丁成功合并到真实仓库中表明，生成的修复不仅在语法上是正确的，而且在语义上是有效的，并且能够被人类开发者接受。
• 方法论新颖性：这项工作强调，将结构化领域知识（DSL）与 LLM 的语义推理能力相结合，是修复低级、安全敏感代码的一种可行策略，在这些代码中，传统的静态分析无法推断出必要的上下文。
• 可扩展性：该框架通过将修复逻辑（静态分析）与最终验证（硬件执行）解耦，解决了“交叉编译”和“硬件隔离”挑战，从而实现了一个实用的修复循环。

作者指出了局限性，包括目前专注于 ARM TrustZone（尽管 DSL 是平台无关的），以及由于 TEE 环境中自动化模糊测试的困难而依赖手动构建的测试用例。然而，他们断言，该方法为保护 TEE 生态系统迈出了重要的一步。