UIEE: Secure and Efficient User-space Isolated Execution Environment for Embedded TEE Systems

UIEE: Secure and Efficient User-space Isolated Execution Environment for Embedded TEE Systems

Speakers: Huaiyu Yan

Conference: NDSS Symposium 2026

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

Overview

Current ARM TrustZone-based Trusted Execution Environments (TEEs) are designed for compact, security-focused operations like cryptographic computations, but they lack the runtime support needed for complex applications like databases, media codecs, or machine learning inference. This talk presents UIEE (User-space Isolated Execution Environment), a TrustZone-oriented system that creates a third execution domain -- separate from both the Rich Execution Environment (REE) and the TEE -- capable of running unmodified Linux applications inside the trusted world with minimal performance overhead and only 8,000 lines of added code (a 46% TCB increase).

UIEE achieves this by integrating a Library OS (LibOS) based on the Linux Kernel Library (LKL/AKR) into the TEE, providing standard C runtime and system call support without the full weight of a Linux kernel. Two key technical innovations -- a two-stage bootstrapping mechanism and on-demand thread migration -- solve the challenges of creating and managing threads in an environment that natively lacks POSIX threading support. Evaluation on eight real-world applications including SQLite, various codecs, OpenSSL, and machine learning workloads shows UIEE introduces very low runtime overhead while outperforming prior work (TrustShadow and Shelter).

Background

▶ Watch: The problem: TEEs are too limited for complex applications (0:00)

ARM TrustZone divides system resources into two domains: the Rich Execution Environment (REE) for normal applications with full functionality, and the Trusted Execution Environment (TEE) for trusted applications with security-oriented but limited capabilities. This hardware-enforced separation provides strong isolation but creates a practical limitation: TEE applications can only use a restricted set of APIs and system calls, preventing complex software from running in the trusted world.

This limitation is becoming increasingly problematic as use cases for secure computation expand beyond simple cryptographic operations. Organizations want to run secure database queries, confidential machine learning inference, secure media processing, and image/video codecs inside TEEs, but these applications require full C runtime support, filesystem access, threading, and other Linux capabilities that the TEE does not natively provide.

Previous approaches to expanding TEE capabilities include TrustShadow and Shelter, which enable richer trusted applications but incur significant performance overhead due to their exception-level switching architecture. Both systems require two EL0-to-EL1 transitions and four EL1-to-EL3 switches for a single system call, creating a performance bottleneck for I/O-intensive applications.

Key Findings

▶ Watch: AKR Library OS four-layer architecture (4:00)

UIEE's architecture creates a third execution domain that sits between the REE and TEE, providing:

Security through isolation: The UIEE memory region is configured as secure memory using the TrustZone Address Space Controller (TZASC), isolating it from the REE while operating within the trusted world. This provides hardware-enforced protection equivalent to TEE isolation.

Rich runtime support: By integrating a LibOS based on LKL, UIEE provides standard C library APIs and Linux system call semantics to applications running in the trusted world. Applications do not need modification to run inside UIEE.

Minimal TCB increase: Only 8,000 lines of code are added to the system, resulting in a 46% TCB increase and a 3.77% increase in the Trusted OS image size. These are characterized as trivial increases relative to the functionality gained.

Superior performance: For single system calls, UIEE uses only a user-space function call instead of the multiple exception-level switches required by TrustShadow and Shelter. This translates to measurably better performance on benchmarks, particularly the SQLite database workload where UIEE outperforms both prior systems.

Technical Deep Dive

▶ Watch: Two-stage bootstrapping: REE init then TEE migration (6:00)

UIEE's architecture has four layers built on the AKR (LKL variant) Library OS:

Application layer: Unmodified user-space Linux applications.

Guest LibC: A customized C library providing standard APIs to applications.

AKR kernel: A Library OS based on the Linux kernel that provides system call services through function calls instead of traps -- the key performance advantage over traditional approaches.

Host LibC: A standard C library providing dependency functions for the AKR host interfaces.

Two-Stage Bootstrapping solves the thread creation challenge:

• Stage 1 (REE): After secure boot, the UIEE loader allocates memory using Linux's continuous memory allocator, loads application binaries and libraries, relocates images, initializes stacks and heaps, creates threads using host LibC (which has POSIX threading support), and completes AKR initialization.
• Stage 2 (TEE): The UIEE session manager reconfigures the UIEE memory region as secure memory using TZASC, loads a new TEE-side library (LibTE) to implement AKR host interfaces inside the secure world, creates thread contexts within the Trusted OS, and manages the UIEE lifecycle.

On-Demand Thread Migration solves the thread context switching challenge. Since AKR thread context is managed by both user-space and the Linux kernel, and the kernel context is not accessible from inside the TEE, UIEE reconstructs thread contexts inside the Trusted OS only when an AKR thread is actually scheduled. When a thread switch occurs, the system redirects the corresponding futex system call back to the Linux kernel, then resumes execution inside the UIEE with a reconstructed thread context.

Memory isolation uses a reconstructed page table inside the Trusted OS based on the original page table from Stage 1, with the UIEE memory region occupying the first 1GB of virtual address space.

Demo / Proof of Concept

▶ Watch: Only 8,000 lines added, 46% TCB increase, minimal overhead (10:00)

The prototype was developed on a Cortex-A9 board and evaluated against eight real-world applications:

• SQLite database operations
• Video/image codecs
• OpenSSL cryptographic operations
• Machine learning inference workloads
• Various data processing applications

Results show UIEE preserves all original TEE functionalities while introducing very little performance overhead across all application categories. The SQLite benchmark comparison against TrustShadow and Shelter shows UIEE outperforming both prior systems, consistent with the reduced exception-level switching overhead.

The system is open-source and publicly available.

Defensive Implications

▶ Watch: SQLite benchmark: UIEE outperforms TrustShadow and Shelter (12:00)

UIEE expands the practical scope of TEE-protected computation for embedded and IoT systems. For defenders, this means:

Broader secure computation: Applications that previously could not run inside TEEs due to runtime limitations -- databases, ML models, media processing -- can now be protected by hardware-enforced isolation. This enables new use cases like secure edge inference, confidential sensor data processing, and protected database queries on embedded devices.

Reduced attack surface versus whole-system TEE: By using a LibOS instead of a full Linux kernel inside the TEE, UIEE keeps the TCB significantly smaller than approaches that run a complete OS in the trusted world. The 8,000 LOC addition is modest compared to the millions of lines in a full Linux kernel.

Performance-viable security: The function-call-based system call interface eliminates the performance penalty that previously made rich TEE applications impractical. This removes a common objection to deploying complex applications inside TEEs.

Compatibility with existing code: Unmodified Linux applications can run inside UIEE, reducing the development effort and expertise required for TEE deployment in embedded systems.

Key Takeaways

• Current ARM TrustZone TEEs lack runtime support for complex applications, limiting TEE use to simple cryptographic operations
• UIEE creates a third execution domain with hardware-enforced isolation and full Linux application support
• Two-stage bootstrapping initializes threads in REE then migrates to secure world; on-demand thread migration handles context switching
• Only 8,000 lines of code added (46% TCB increase, 3.77% Trusted OS image increase)
• Function calls replace exception-level switches for system calls, outperforming TrustShadow and Shelter
• Eight real-world applications evaluated including SQLite, codecs, OpenSSL, and ML inference
• Prototype is open-source and developed on Cortex-A9

About the Speaker(s)

The paper was presented by a colleague (not identified by name in the transcript) on behalf of the original authors, as none could attend. The presenter is described as a networking researcher rather than a systems security specialist, but delivered the presentation effectively. The research team focuses on ARM TrustZone security, Library OS design, and embedded systems security. The work is open-source.