SoK: Analysis of Accelerator TEE Designs

SoK: Analysis of Accelerator TEE Designs

Speakers: Chenxu Wang

Conference: NDSS Symposium 2026

YouTube: https://www.youtube.com/watch?v=ZUkNj5Xz9D8

Overview

As AI workloads move to GPUs, TPUs, FPGAs, and other accelerators (collectively "XPUs"), the need to extend Trusted Execution Environment (TEE) protections beyond CPUs has become urgent. This Systematization of Knowledge (SoK) paper surveys 51 academic and industry accelerator TEE studies across GPU, NPU, TPU, and FPGA-based designs, categorizing them into three architectural types, analyzing their security mechanisms, and identifying critical deployment gaps. The most alarming finding: 34 out of 44 surveyed accelerators lack attestation support, meaning there is no way to verify the integrity of the execution environment -- a fundamental security guarantee.

The research, conducted jointly by Southern University of Science and Technology, Hong Kong Polytechnic University, Chinese Academy of Sciences, and NVIDIA (N Group), provides the first systematic analysis of how accelerator TEEs differ from CPU TEEs and identifies two key deployment challenges: compatibility (most designs require hardware/software modifications specific to one accelerator type) and TCB bloat (incorporating accelerator software stacks dramatically increases the trusted computing base).

Background

▶ Watch: Definition: what is an accelerator TEE and why do we need one (0:00)

CPU-based TEEs like Intel SGX/TDX, AMD SEV, and ARM TrustZone are well-established technologies for isolating sensitive computations. They provide confidentiality (data encrypted in memory), integrity (tampering detected), and attestation (remote verification of the execution environment). As AI and accelerated computing have grown, extending these protections to accelerators has become a pressing need.

Accelerator TEEs face unique challenges that CPU TEEs do not. Accelerators communicate with the host CPU via PCIe, creating an additional attack surface for bus-level eavesdropping. They have their own memory systems, firmware, and software stacks that are architecturally different from CPU-side memory management. The driver stacks required to communicate with accelerators (CUDA, ROCm, etc.) are massive and must be included in the TCB, dramatically increasing the code that must be trusted.

Since 2022, approximately 40 papers have been published on accelerator TEEs, reflecting rapid growth but lacking systematic analysis of design patterns, security gaps, and deployment challenges. The only commercially deployed accelerator TEE as of the talk is the NVIDIA Hopper series GPU, with a 30-40% performance overhead compared to non-TEE operation.

Key Findings

▶ Watch: Memory encryption: PCIe eavesdropping and 30 of 51 studies impacted (4:00)

The SoK categorizes accelerator TEEs into three architectural types:

Host-type: Modifications are made on the CPU side to extend existing CPU TEE protections to cover accelerator interactions. The CPU TEE manages isolation while the accelerator operates relatively unmodified.

Accelerator-type: Hardware or software modifications are made on the XPU itself to provide TEE capabilities natively. The accelerator has its own security mechanisms independent of CPU TEE support.

Mixed-type: Both CPU and accelerator sides are modified, providing defense-in-depth but at greater complexity and deployment cost.

The three defense mechanisms mirror CPU TEE approaches:

Access control: Applied at various granularities depending on hardware primitives. Some designs use high-privilege modes (ARM monitor, RISC-V M-mode) to enforce isolation, but this bloats the system TCB.

Memory encryption: Impacts more than half of surveyed designs (30 of 51). PCIe bus eavesdropping is a real threat in cloud environments for discrete accelerators. For integrated accelerators (SoCs), shared memory protection is needed. Communication overhead from frequent metadata access between CPU and XPU is a significant performance concern.

Attestation: The most critical gap. 34 of 44 surveyed accelerators lack attestation support, meaning users cannot verify the integrity of the accelerator TEE environment. Only three vendors have full attestation mechanisms. Without attestation, malicious firmware injection (demonstrated by the MoA paper at CCS 2024, which injected malicious MCU firmware to break GPU TEE) is a viable attack.

Technical Deep Dive

▶ Watch: Attestation crisis: 34 of 44 accelerators lack attestation support (6:00)

The attestation gap deserves particular attention. CPU TEEs provide attestation through hardware roots of trust (TPMs, Intel's DCAP infrastructure, AMD's SEV attestation server). Accelerator TEEs largely lack equivalent hardware, meaning:

1. Users cannot verify that the accelerator TEE is running legitimate firmware
2. Supply chain attacks on accelerator firmware are undetectable
3. Runtime attestation (verifying integrity during computation, not just at boot) is almost entirely absent -- most attestation happens only at boot/initialization

The TCB bloat problem is structural. To support an accelerator TEE, the guest TCB must include:

• Heavy-weight accelerator software stacks (drivers like CUDA, ROCm, etc.)
• Additional code for security features (encryption, access control, attestation)
• High-privilege mode code on the CPU side (ARM monitor, RISC-V M-mode) for access control enforcement

This is significantly larger than CPU TEE TCBs, which increases the attack surface that TEEs are designed to minimize.

The compatibility problem has two dimensions. Multi-type support is lacking: most accelerator TEEs depend on specific CPU features (e.g., only Intel TDX or only AMD SEV) and are designed for specific accelerator types (only NVIDIA GPUs or only certain FPGAs). Plug-and-play support is absent: deploying an accelerator TEE typically requires modifying accelerator drivers, importing TEE-specific APIs, and sometimes modifying hardware (CPU ISA, PCIe bus, accelerator hardware). The team's separate work on CCAI (published at MICRO 2025) addresses compatibility by operating at the PCIe level to support multiple accelerator types with less than 5% performance overhead for LLM workloads.

Demo / Proof of Concept

▶ Watch: Key problems: compatibility and TCB bloat (10:00)

This is a systematization paper, so no novel attack or system demo was presented. The contribution is the comprehensive survey and taxonomy of 51 studies, the identification of critical gaps (attestation, compatibility, TCB), and the three-type classification framework. The speaker referenced the MoA attack (CCS 2024) as a concrete demonstration of what happens when accelerator attestation is missing -- malicious MCU firmware was injected to break GPU TEE guarantees.

Defensive Implications

▶ Watch: Q&A: NVIDIA Hopper 30-40% overhead vs CCAI at less than 5% (12:00)

For organizations deploying AI workloads on accelerators in security-sensitive environments:

Attestation is the critical gap. If you cannot attest the accelerator's execution environment, you cannot trust the computation. Only three vendors currently provide full attestation for accelerator TEEs. Organizations should require attestation support as a procurement criterion for accelerator hardware used in sensitive workloads.

TCB awareness is essential. Including GPU driver stacks in the TCB means trusting millions of lines of proprietary code. Security teams should understand the TCB implications of accelerator TEE deployments and evaluate whether the expanded TCB is acceptable for their threat model.

Performance-security tradeoffs vary widely. NVIDIA Hopper TEE imposes 30-40% overhead, while the CCAI approach achieves less than 5% for LLM workloads. Organizations should evaluate these tradeoffs rather than assuming a single performance penalty.

Runtime attestation is missing. Even when boot-time attestation exists, runtime integrity verification is almost entirely absent. This means firmware compromise during execution would go undetected.

Key Takeaways

• 51 accelerator TEE studies surveyed, categorized into host-type, accelerator-type, and mixed-type architectures
• 34 of 44 surveyed accelerators lack attestation support -- the most critical security gap
• Only three vendors have full attestation mechanisms for accelerator TEEs
• Incorporating accelerator software stacks (CUDA, ROCm, drivers) dramatically bloats the Trusted Computing Base
• Most accelerator TEE designs lack multi-type and plug-and-play compatibility, requiring extensive hardware/software modifications
• NVIDIA Hopper is the only commercially deployed accelerator TEE, with 30-40% performance overhead
• Runtime attestation is nearly absent across all designs -- most attestation occurs only at boot time
• PCIe bus eavesdropping is a real threat requiring memory encryption for discrete accelerators

About the Speaker(s)

The talk was presented by Fengwei Zhang (not Chenxu Wang as listed), an associate professor at the Southern University of Science and Technology. The research was conducted jointly with Hong Kong Polytechnic University, Chinese Academy of Sciences, and NVIDIA (N Group). The team also published related work on the CCAI system at MICRO 2025, which addresses accelerator TEE compatibility at the PCIe level. Professor Zhang's lab focuses on trusted execution environments, hardware security, and accelerator architecture.