Technical Summary: Automated Repair of TEE Partitioning Issues via DSL-Guided and LLM-Assisted Patching

1. Problem Statement

Trusted Execution Environments (TEEs) provide hardware-based isolation to protect sensitive data and computations from untrusted operating systems. However, TEE applications must interact with the untrusted OS via software interfaces (SDKs). Improper partitioning between the "normal side" (untrusted) and the "secure side" (trusted) introduces severe vulnerabilities, collectively termed bad partitioning issues. These include:

1. Unencrypted Data Output: Sensitive data (e.g., keys, tokens) transferred from TEE to the normal side without encryption.
2. Input Validation Weaknesses: Insufficient checks on inputs passed from the normal side, leading to buffer overflows or memory corruption within the TEE.
3. Direct Usage of Shared Memory: Reliance on shared memory regions controlled by the untrusted OS without integrity verification, allowing tampering.

While static analysis tools exist to detect these issues, automated repair remains largely unexplored due to three specific challenges:

• Lack of Standard Guidelines: Unlike general software security (e.g., OWASP), TEE development lacks standardized secure partitioning practices, making it difficult to define reliable ground truths for repair.
• Semantic Extraction Difficulty: TEE applications are often written in low-level C, where semantic information (e.g., buffer sizes, valid index ranges) is implicit or dynamic, making it hard for static tools to infer correct repair parameters.
• Absence of Mature Testing: TEE environments restrict debugging and monitoring. Most projects lack unit tests or regression suites, and cross-compilation requirements make the generate-compile-test cycle expensive and complex.

2. Methodology: TEERepair

The authors propose TEERepair, a framework that combines a Domain-Specific Language (DSL) for encoding repair rules with Large Language Models (LLMs) for context-aware semantic synthesis. The workflow consists of six steps:

A. DSL-Guided Repair Templates

To address the lack of guidelines, the authors designed a DSL to formally encode secure TEE partitioning patterns.

• Grammar: The DSL defines nodes for common TEE operations (e.g., COPY, MALLOC, ENC, HASH) and conditional guards (IF).
• Repair Rules: The DSL encodes three types of transformation rules corresponding to the vulnerability categories:
  • Rule 1 (Encryption): Replaces direct data copying with a sequence of memory allocation, encryption (ENC), and copying of ciphertext.
  • Rule 2 (Validation): Inserts conditional guards (IF) before data usage to check buffer sizes or array indices against bounds.
  • Rule 3 (Shared Memory): Replaces shallow copies of shared memory with deep copies into TEE-internal buffers, followed by integrity checks (hashing) before use.
• Templates: These DSL rules are instantiated into patch templates containing placeholders (e.g., $cipher, $len) for context-specific variables.

B. LLM-Assisted Placeholder Synthesis

To address the difficulty of extracting semantic information from low-level C code:

• Prompting: The system constructs prompts containing the vulnerable code snippet, the issue type, and the DSL-generated patch template.
• Inference: The LLM (specifically gpt-4.1-mini) analyzes the code context to infer the correct values for placeholders (e.g., identifying which variable represents the buffer size or which cryptographic key to use).
• Constraint: The LLM is restricted to filling placeholders rather than generating code from scratch, reducing the risk of syntactic errors and hallucinations.

C. Two-Stage Validation Pipeline

To address the lack of mature testing and hardware constraints:

1. Stage 1: Static Feedback (Repair Phase): A static analyzer (DITING) re-analyzes the patched code to verify that the vulnerable pattern is eliminated. If the issue persists, feedback is provided to the LLM for refinement. This occurs without hardware execution.
2. Stage 2: Runtime Validation (Functional Phase): Once static analysis passes, the system automatically synthesizes a test client (a normal-side program) based on the TEE source code's entry points and parameters. This client is compiled and executed on real TEE hardware (e.g., Raspberry Pi 3B with TrustZone) to verify that the patch compiles, runs, and produces expected security outputs (e.g., correct ciphertext, proper error codes for invalid inputs).

3. Key Contributions

• TEERepair Framework: The first automated repair framework specifically designed for TEE bad partitioning issues, bridging the gap between static detection and automated fixing.
• DSL for TEE Security: A novel Domain-Specific Language that encodes secure partitioning patterns as structured transformations, providing a reliable ground truth in the absence of standard guidelines.
• LLM-DSL Synergy: A hybrid approach where DSLs provide structural security knowledge and LLMs resolve context-dependent semantic ambiguities in low-level C code.
• Automated Test Client Generation: A method to automatically generate test clients and validation cases for TEE applications, overcoming the scarcity of existing test suites.
• Benchmark and Evaluation: The application of TEERepair to PartitioningE-Bench, a benchmark containing 89 real-world bad partitioning cases across multiple projects.

4. Experimental Results

The authors evaluated TEERepair on PartitioningE-Bench and compared it against baselines including template-based tools (TBar, Prophet), learning-based tools (VulMaster), and LLM-based tools (ChatRepair, SAN2PATCH).

• Repair Success Rate: TEERepair achieved a 87.6% success rate (78 out of 89 vulnerabilities correctly fixed).
  • Unencrypted Data Output: 94.3% (33/35).
  • Input Validation Weaknesses: 67.0% (20/29).
  • Direct Usage of Shared Memory: 100% (25/25).
• Baseline Performance: The next best performer, TBar, achieved only 19.1% (17/89). Other tools performed significantly worse, with many failing to generate any correct patches for shared memory issues.
• Ablation Study: Removing either the DSL or the LLM drastically reduced performance (DSL-only: 22.5%; LLM-only: 13.4%), confirming that both components are essential.
• Real-World Validation: The authors applied TEERepair to real-world GitHub projects. They submitted 5 pull requests, 2 of which were confirmed and merged by project maintainers (in projects basicAlg_use and PPFL).

5. Significance and Claims

The paper claims that TEERepair demonstrates the feasibility of automating the repair of complex, security-critical vulnerabilities in TEE applications, a domain previously considered too challenging for automated tools due to the lack of guidelines and testing infrastructure.

• Practical Applicability: The successful merging of patches into real-world repositories indicates that the generated fixes are not only syntactically correct but also semantically valid and acceptable to human developers.
• Methodological Novelty: The work highlights that combining structured domain knowledge (DSL) with the semantic reasoning capabilities of LLMs is a viable strategy for repairing low-level, security-sensitive code where traditional static analysis fails to infer necessary context.
• Scalability: The framework addresses the "cross-compilation" and "hardware isolation" challenges by decoupling the repair logic (static analysis) from the final validation (hardware execution), enabling a practical repair loop.

The authors note limitations, including the current focus on ARM TrustZone (though the DSL is platform-agnostic) and the reliance on manually constructed test cases due to the difficulty of automated fuzzing in TEE environments. However, they assert that the approach provides a significant step forward in securing TEE ecosystems.