Trusted Execution Environment Containers

• TEE Containers are container frameworks that run standard application binaries within hardware-enforced isolated environments using mechanisms like Intel SGX, AMD SEV, or Arm TrustZone.
• They employ various isolation techniques—including LibOS, libc-wrapper, WASM runtimes, and VM-based schemes—to guarantee confidentiality, integrity, and availability against adversarial host environments.
• Recent research highlights trade-offs in performance, TCB minimization, and secure orchestration, emphasizing formal threat models, policy-driven attestation, and improved syscall sanitization.

A Trusted Execution Environment (TEE) Container is a containerization framework or middleware that executes standard, unmodified application binaries within a hardware-enforced isolated environment. TEE containers leverage hardware isolation features—such as those offered by Intel SGX, Intel TDX, AMD SEV(-SNP), or Arm TrustZone—to provide robust confidentiality and integrity guarantees for containerized workloads under attack models where the operating system, hypervisor, and orchestration layers are assumed to be adversarial. This paradigm shifts trust from operating system/kernel-level isolation (e.g., namespaces, cgroups in Docker) to CPU-rooted, cryptographically attested execution environments, thereby addressing core privacy and integrity concerns in both cloud-native and edge computing contexts (Paju et al., 2023, Brasser et al., 2022, Liu et al., 28 Aug 2025, Michaud et al., 26 Dec 2025).

1. Taxonomy and Architectural Principles of TEE Containers

TEE containers (abbreviated as "tcons" in several technical reviews) are systematized based on their application middleware interface, the degree and locus of isolation enforced, their trust model, and deployment backends. Major architectural styles include:

• Library-OS (LibOS) based: Embedding a full or minimal OS kernel as a library inside the enclave/TEE, providing a POSIX-like ABI to unmodified Linux binaries (e.g., Gramine/Graphene-SGX, Mystikos, Occlum) (Paju et al., 2023, Michaud et al., 26 Dec 2025). These typically mediate system calls via a PAL (Platform Abstraction Layer) within the TEE.
• libc-wrapper: Intercepts library calls at the libc boundary and forwards/marshals these across enclave/VM boundaries (e.g., Deflection, GoTEE, Ratel) (Paju et al., 2023).
• WebAssembly (Wasm) Runtime: Executes WASM binaries inside a minimal enclave or VM, decoupling host interactions using a standard system interface (WASI), frequently implemented by sandboxes such as Enarx or Twine (Michaud et al., 26 Dec 2025).
• VM-based TEE containers: Leverage per-container VM isolation under TEE technologies (SEV, TDX) to run minimal container images within fully hardware-shielded domains (e.g., Trusted Container Extensions (TCX), Parma, Arca) (Brasser et al., 2022, Johnson et al., 2023, Lu et al., 3 Jan 2026).

This taxonomy is summarized below:

TEE Container	Middleware	Isolation	Hardware TEE
Graphene-SGX	LibOS	Addr.sp.	Intel SGX
Occlum	LibOS (Rust)	Process SFI	Intel SGX
Enarx	WASM/WASI	Wasm sandbx	SGX, SEV
TCX	Container VM	Full-VM	AMD SEV
Parma	Container VM	Full-VM + attestation policy	AMD SEV-SNP
Arca	Minimal enclave per container	Per-container	SGX, TDX, SEV

(Paju et al., 2023, Brasser et al., 2022, Michaud et al., 26 Dec 2025, Johnson et al., 2023, Lu et al., 3 Jan 2026)

2. Trust Boundaries, Threat Models, and Security Guarantees

Formalizations in recent work model a TEE container as a triple $(A, R, H)$, where $A$ is the application state, $R$ is the trusted runtime (LibOS or secure monitor), and $H$ is the untrusted host and orchestration environment (Liu et al., 28 Aug 2025). The goal is to secure:

• Confidentiality(A): $H$ learns nothing about $A$'s state ($\alpha\in\Sigma_A$).
• Integrity(A): $H$ cannot corrupt $\alpha$ without detection.
• Availability(A): $R$ must forward valid requests within a bounded time.

Threat models universally assume that the OS, hypervisor, and any orchestration interface (e.g., Kubernetes CRI) can be fully controlled or subverted by the adversary, whereas the hardware TEE and its local firmware/PSP are part of the trusted computing base (TCB). Attestation binds particular code measurements and—in advanced systems—container policies or manifests to a public, verifiable state (cf. Parma’s inductive policy proof (Johnson et al., 2023)).

Key security properties provided by mature TEE container designs include:

• Non-bypassable per-container memory encryption (SGX EPC, TDX encrypted EPT, SEV VEK) ensures that the host cannot access plaintext application code/data (Brasser et al., 2022, Lu et al., 3 Jan 2026).
• Measured launch and remote attestation tie the workload’s launch state to an externally-fetched quote, enabling key provisioning or secret injection only for trusted images (Brasser et al., 2022, Johnson et al., 2023, Lu et al., 3 Jan 2026).
• Policy-driven enforcement (e.g., Parma) guarantees that only user-approved image layers, environment variables, and command-lines are ever used, effectively inductively bounding reachable futures of the container VM (Johnson et al., 2023).

3. Isolation Techniques and In-Enclave Privilege Separation

TEE containers deploy a variety of cross-layer and in-enclave isolation mechanisms:

• Namespace and cgroup partitioning: Traditional Linux containers, often reused for process or network separation even under TEE (Liu et al., 28 Aug 2025).
• In-enclave/data-structure privilege separation: EnclaveDom partitions a single SGX enclave’s heap into memory domains using Intel Memory Protection Keys (MPK), mapping sensitive OS/data structures to per-domain regions and controlling access on a per-function basis using PKRU manipulations. This model expresses access policies as $I(f)$ (read domains) and $O(f)$ (read/write domains) for each function $f$, strictly enforcing least-privilege at runtime (Melara et al., 2019).
• Software Fault Isolation (SFI) and sandboxing: Software techniques (IRM/MPX instrumentation, Wasm sandboxes) add in-enclave process separation, as in Occlum AE, Chancel, Deflection, Ryoan, and Wasm-based runtimes (Liu et al., 2021, Michaud et al., 26 Dec 2025).
• File and network I/O protection: Encrypted filesystems (e.g., dm-crypt/dm-integrity for VM-based, PF in Gramine/LibOS), attested TLS sockets, and I/O mediation through secure channels (Brasser et al., 2022, Liu et al., 28 Aug 2025, Michaud et al., 26 Dec 2025).
• World partitioning on MCUs: uTango (for TrustZone-M) implements OS-less, multi-container isolation on Arm MCUs using hardware SAU/MPU configuration, register-based WCC, and per-world context handling (Oliveira et al., 2021).

Isolation techniques are evaluated formally using invariants such as:

• Confidentiality: $$\forall \alpha_1,\alpha_2 \in \Sigma_A,\, \forall p \in IO^*,\, Obs(p,\alpha_1)=Obs(p,\alpha_2)$$.
• Integrity: $\forall i\in IO,\; m,\quad R(i,S_i(m))=R(i,m)$, where $S_i$ is the sanitizer for I/O call $i$ (Liu et al., 28 Aug 2025).

4. Security Gaps and Lessons from Empirical Studies

Large-scale analyses of TEE containers have identified recurring shortcomings:

• Incomplete syscall and parameter sanitization: Libc-shim models forward excessive syscalls without effective argument or return-value checks, making them susceptible to Iago attacks and covert channels. Even LibOS-based containers often leave configuration file integrity unchecked (Liu et al., 2021, Liu et al., 28 Aug 2025).
• Deficiencies in SFI instrumentation: IRM/MPX guards in, e.g., Occlum AE, Deflection, Chancel, exhibit gaps such as direct jump bypasses and coarse bounds on heap partitioning, failing to block certain memory exploits (Liu et al., 2021).
• Side-channel vulnerabilities: Most TEE containers either do not address or explicitly leave microarchitectural side-channels out of scope (Liu et al., 2021, Liu et al., 28 Aug 2025).
• Manifest/attestation gaps: Host-provided configuration or orchestration metadata (e.g., Kubernetes manifests, mount tables, overlays) are often omitted from TEE attestation, enabling attack vectors like manifest-swap or rollback attacks (Liu et al., 28 Aug 2025, Johnson et al., 2023).

Empirical analyses leverage semi-automated tools (TECUZZER, TBouncer) combining syscall fuzzer frontends inside the TEE with host-side response manipulation, validating the criticality of argument/return-value checks, minimal exposed syscalls, and the value of strong, minimal TCB isolation domains (Liu et al., 2021, Liu et al., 28 Aug 2025).

5. Performance, Usability, and TCB Trade-offs

TEE containers balance performance, compatibility, and TCB minimization in distinct ways:

• Performance: Single-digit to low double-digit % overhead on compute-bound workloads is typical for VM TEEs (SEV, TDX, Arca, Parma, TCX) (Brasser et al., 2022, Johnson et al., 2023, Lu et al., 3 Jan 2026). Some I/O-intensive or memory-heavy workloads can incur up to 20–30% penalty, primarily from encrypted I/O and VM memory isolation (Brasser et al., 2022, Johnson et al., 2023).
• Usability: WASM-based containers (Enarx, Twine) require code adaptation to WASI and WASM targets and are limited by the scope of the standard library. LibOS-based tcons (Gramine-SGX, Occlum) often support unmodified binaries with manifest-based configuration (Paju et al., 2023, Michaud et al., 26 Dec 2025).
• TCB Analysis: Library-OS and Container-in-TEE models tend to inflate the TCB (hundreds of KLoC), making formal verification and security auditing prohibitive. Minimal models (Arca, uTango) and per-container TEE mapping (Arca's 1C:1T design) show 80–90% reduction in TCB lines of code (Lu et al., 3 Jan 2026, Oliveira et al., 2021).
• Isolation Granularity: Per-container TEE instantiation (e.g., "one container, one TEE" in Arca) maximizes compromise containment. By contrast, conventional Container-in-TEE approaches risk cross-container escalation within a single large TCB (Lu et al., 3 Jan 2026, Michaud et al., 26 Dec 2025).

6. Emerging Trends and Research Frontiers

Recent advances and ongoing research highlight:

• Policy-driven and attested container execution: Parma demonstrates inductive attestation policies (in Rego), enabling not only initial state measurements but future execution states and enforcement of workflow constraints to be cryptographically committed at attestation time (Johnson et al., 2023).
• TEE-in-Container over Container-in-TEE inversion: Arca favors per-workload trust domains, placing only critical logic in the TEE and keeping orchestration excluded, yielding both performance gains and auditable trust boundaries (Lu et al., 3 Jan 2026).
• WebAssembly as a universal TEE abstraction: WASI containers enable hardware-agnostic, cross-ISA, and capability-based application deployment with a minimal TCB, universal binary format, and tractable verification surface (Michaud et al., 26 Dec 2025, Paju et al., 2023).
• Hardening and formal verification: Recommendations include adopting proof-carrying code at syscall boundaries, verified in-enclave filesystems (e.g., BesFS), and minimal manifest-driven host interaction (Liu et al., 28 Aug 2025, Michaud et al., 26 Dec 2025).
• Kubernetes and confidential orchestration: Integration of attestation APIs, node tainting (for TEE capability), manifest scheduling, and rolling secret rotation is suggested as a future direction for TEE-enhanced cloud-native infrastructure (Michaud et al., 26 Dec 2025, Liu et al., 28 Aug 2025).

7. Representative Implementations and Comparative Table

Below is a summary table comparing major TEE container frameworks by design style, hardware TEE, primary isolation, and TCB implications:

Framework	Design Model	Hardware TEE	Primary Isolation	TCB Size	Typical Overhead
Graphene-SGX	LibOS	SGX	Addr.space, per-enclave	small	low
Occlum	LibOS+SFI	SGX	Process SFI	small	low
Enarx	WASM Runtime	SGX, SEV	Wasm sandbox, per-keep	minimal	low–medium
TCX	Per-VM	SEV	VM-level (per container)	moderate	~5–22%
Parma	Per-VM, Policy	SEV-SNP	VM-level + policy attestation	moderate	0–26%
Arca	1C:1T, per-app	SGX, TDX, SEV	per-container TEE	minimal (~30k)	~5–10%
uTango	Multi-world	TrustZone-M	Per-NSVW hardware partitions	~4kB	<0.1%

(Paju et al., 2023, Michaud et al., 26 Dec 2025, Brasser et al., 2022, Johnson et al., 2023, Oliveira et al., 2021, Lu et al., 3 Jan 2026)

In summary, TEE containers have rapidly matured into a central abstraction for confidential, cloud-native, and IoT computing. They provide strong isolation by mapping existing application containers to CPU-rooted hardware TEEs, backed by formal threat models, cryptographic attestation, and—in recent work—minimized, verifiable TCBs with policy-enforced integrity over entire application lifecycles. Nevertheless, caution is necessary: practical deployments must scrutinize and harden syscall surfaces, in-enclave privilege domains, attestation coverage, and orchestration interfaces to approach the stringent guarantees posited by the underlying TEE hardware (Paju et al., 2023, Liu et al., 2021, Liu et al., 28 Aug 2025, Michaud et al., 26 Dec 2025, Melara et al., 2019, Lu et al., 3 Jan 2026).