TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption
Martin Unterguggenberger
Network and Distributed System Security (NDSS) Symposium 2025 · Day 2 · Confidential Computing 1
Overview
In the realm of modern cloud computing, the relentless pursuit of performance and efficiency has driven a shift from heavyweight process isolation to more lightweight, in-process sandboxes. While this approach offers significant performance benefits, it inherently introduces security risks, particularly memory safety errors that can lead to the leakage of sensitive data, such as cryptographic keys or authentication tokens. Historical vulnerabilities like Heartbleed and Cloudbleed serve as stark reminders of these dangers. "TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption," presented by Martin Unterguggenberger at the NDSS Symposium, directly addresses this critical challenge.
Key moments
- 0:00 Introduction to TME-Box and problem statement
- 2:05 Understanding Intel TME-MK memory encryption
- 4:00 Core idea: Designing sandboxes using TME-MK
- 6:00 Achieving subpage granular memory isolation
- 7:00 Flexible memory management and data relocation
- 8:00 TME-Box framework: compiler, allocator, kernel support
- 9:00 Performance evaluation setup and overhead identification
TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption
Speakers: Martin Unterguggenberger
Conference: NDSS Symposium
YouTube: https://www.youtube.com/watch?v=cTmZ1eCs08E
Overview
In the realm of modern cloud computing, the relentless pursuit of performance and efficiency has driven a shift from heavyweight process isolation to more lightweight, in-process sandboxes. While this approach offers significant performance benefits, it inherently introduces security risks, particularly memory safety errors that can lead to the leakage of sensitive data, such as cryptographic keys or authentication tokens. Historical vulnerabilities like Heartbleed and Cloudbleed serve as stark reminders of these dangers. "TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption," presented by Martin Unterguggenberger at the NDSS Symposium, directly addresses this critical challenge.
This talk introduces TME-Box, an innovative framework that repurposes Intel Total Memory Encryption Multi-Key (TME-MK) for robust in-process isolation. By leveraging commodity x86 hardware, TME-Box provides fine-grained and scalable memory isolation, enforcing that sandboxes utilize their designated encryption keys for all memory interactions. The core contribution lies in its ability to offer hardware-assisted security with minimal performance overheads, reporting an impressive 5.2% for data isolation and 9.7% for combined code and data isolation, making it a compelling solution for securing performance-critical cloud workloads.
Background
▶ Watch: Introduction to TME-Box and problem statement (0:00)
The evolution of cloud computing has consistently favored optimization for speed and resource utilization. A key strategy in achieving this has been the move away from traditional, heavy-handed operating system-level process isolation towards more agile, in-process sandboxing mechanisms. While effective in reducing overheads and improving application responsiveness, this paradigm shift inherently compromises the strong security boundaries that process isolation provides. Without these boundaries, a single memory safety vulnerability within an application's process can potentially expose all data within that process, including highly confidential information.
The advent of confidential computing has introduced new hardware features to x86 servers, specifically designed to enhance data protection. Central to TME-Box's design is Intel Total Memory Encryption Multi-Key (TME-MK), an architectural feature that integrates an encryption engine directly into the memory controller. TME-MK operates by associating a unique Key ID with physical memory pages. This Key ID, encoded into the upper part of the physical address, is transmitted along with the address to the encryption engine. The engine then maps the Key ID to a specific encryption key and mode, enabling page-granular encryption of physical memory. This means different physical pages can be encrypted with distinct keys, providing a foundational layer of memory isolation.
Further enhancing TME-MK, Intel's confidential computing platform, Intel TDX, introduced support for authenticated encryption. This crucial addition provides not only data encryption using AES XTS but also cryptographic integrity through a SHA-3 MAC (Message Authentication Code). When data is written to memory, it is first encrypted, and then a MAC is calculated and stored alongside the encrypted data in DRAM. Conversely, when data is loaded, the MAC is recomputed and compared against the stored MAC. Any mismatch triggers a hardware exception, effectively detecting unauthorized modifications or accesses. TME-MK's integrity enforcement mechanism utilizes a 28-bit MAC, offering strong protection against tampering. This hardware-backed integrity check forms the bedrock of TME-Box's security guarantees, preventing sandboxes from illicitly accessing or corrupting memory not designated for them.
Key Findings
▶ Watch: Core idea: Designing sandboxes using TME-MK (4:00)
The TME-Box project presents several pivotal findings and contributions that significantly advance the state of in-process isolation:
- Repurposing Intel TME-MK for In-Process Isolation: The core innovation is to leverage existing hardware capabilities, specifically Intel's TME-MK, for a novel application: fine-grained, hardware-assisted sandboxing within a single process. This avoids the need for new, specialized hardware and makes the solution readily available on commodity x86 platforms.
- Enforced Key-ID Usage: TME-Box ensures that each sandbox uses its designated encryption key for all memory interactions. This is achieved by associating a unique Key ID with each sandbox and enforcing its use through compiler instrumentation, effectively creating isolated memory regions.
- Scalable and Fine-Grained Isolation: The design achieves unprecedented scalability, enabling memory isolation from individual cache lines up to full pages. This sub-page granularity, facilitated by page aliasing and the cache-line-sized MACs of TME-MK, allows for extremely precise protection of sensitive data.
- Flexible Memory Management: TME-Box supports flexible memory management, including the implementation of allocator caches and efficient relocation of fragmented memory resources. This allows for intermixing of data from different sandboxes on the same physical page, optimizing memory utilization without compromising security.
- High Sandbox Capacity: The TME-MK architecture supports up to 32,000 encryption keys, which directly translates into the potential to isolate up to 32,000 distinct sandboxes within a single process, making it highly suitable for multi-tenant cloud environments.
- Low Performance Overhead: A performance-optimized prototype demonstrates remarkably low overheads: 5.2% for data isolation and 9.7% for code and data isolation when utilizing segment-based addressing (GS mode). This minimal impact on performance makes TME-Box practical for high-throughput cloud applications.
- Hardware-Assisted Integrity and Confidentiality: By utilizing TME-MK's authenticated encryption, TME-Box provides both data confidentiality (encryption) and integrity (MACs), ensuring that unauthorized access or modification of sandbox memory is detected and prevented at the hardware level.
Technical Deep Dive
▶ Watch: Achieving subpage granular memory isolation (6:00)
The technical foundation of TME-Box lies in its ingenious repurposing of Intel's TME-MK capabilities, coupled with a robust software framework comprising compiler extensions, a custom memory allocator, and kernel support.
At the heart of TME-MK is an encryption engine situated within the memory controller. When a memory access occurs, a Key ID is encoded into the upper bits of the physical address. This combined information (Key ID + physical address) is then sent to the encryption engine. The engine uses the Key ID to select a specific encryption key and mode. This mechanism allows for page-granular encryption, meaning different 4KB physical pages can be encrypted with distinct keys. With the introduction of Intel TDX, this was extended to include authenticated encryption, employing AES XTS for data encryption and a SHA-3 MAC for cryptographic integrity. Every write operation involves encrypting the data and computing a MAC, both of which are stored in DRAM. During a read operation, the data is decrypted, and the MAC is recomputed and compared against the stored MAC. A mismatch immediately triggers a hardware exception, signaling a security violation. This 28-bit MAC provides a strong integrity guarantee.
TME-Box designs a sandbox around this primitive by assigning a unique sandbox-specific Key ID to each isolated environment. This Key ID maps to a unique encryption key. For instance, if there are three sandboxes and four physical pages, TME-Box can assign Key ID 1 to Sandbox 1, Key ID 2 to Sandbox 2, and Key ID 3 to Sandbox 3. When Sandbox 1 allocates memory, that memory is associated with Key ID 1 and encrypted accordingly. The crucial enforcement mechanism comes from compiler support: the LLVM compiler extension instruments all memory operations and control flow transfers. This instrumentation ensures that the correct base address and index are used for memory operations, which in turn enforces the use of the designated Key ID for that sandbox. If Sandbox 1 attempts to read memory allocated to Sandbox 3, the hardware detects a MAC mismatch because the data was encrypted with Key ID 3 but accessed with Key ID 1 (or a default key), triggering an integrity exception.
A key design goal for TME-Box was scalable memory isolation, specifically achieving sub-page granularity. This is accomplished through page aliasing. While TME-MK natively provides page-granular encryption, the authenticated encryption mode's MACs are calculated at the cache line level. This means that even within a single physical page, different cache lines can be encrypted with different keys if the memory is initialized appropriately. By mapping multiple virtual addresses, each associated with a different Key ID, to the same physical page, TME-Box can effectively assign parts of that page to different sandboxes. For example, a physical page could be owned by Sandbox 2, but specific cache lines within it could be re-initialized and encrypted with Key ID 3, effectively assigning them to Sandbox 3. Any unauthorized access by Sandbox 2 to these cache lines would again result in a MAC mismatch.
This fine-grained control also enables flexible memory management. The ability to isolate memory down to the cache line allows for advanced allocator strategies, such as allocator caches. Memory from different sandboxes can be interleaved on a single physical page without compromising isolation. Furthermore, TME-Box allows for efficient relocation of data in memory. Sparsely allocated chunks from various sandboxes can be consolidated and relocated onto new physical pages, optimizing memory usage and reducing fragmentation while maintaining their individual encryption and isolation properties.
The TME-Box framework is implemented through three key components:
- LLVM Compiler Extension: This is perhaps the most critical component. It requires reserving a CPU register to store the base address of the sandbox. Two modes are proposed:
- Using the general-purpose register R15.
- Using segment-based addressing where the base address is stored in the GS register.
The compiler instruments all memory operations (loads, stores) and control flow transfers (jumps, calls, returns) to apply the sandbox context. This ensures that memory accesses are correctly bounded and associated with the designated Key ID. The instrumentation for control flow transfers, especially return address protection, is currently done in software, which contributes to some of the overhead.
- Memory Allocator: A custom memory allocator is necessary to initialize and manage runtime data, particularly the heap. Its primary role is to ensure that newly allocated memory is correctly initialized with the appropriate Key ID, which involves writing to the memory to set up the MAC values. This custom allocator works in conjunction with the compiler instrumentation to maintain the integrity of the sandboxed memory.
- Kernel Support: A syscall interface is required to allow user-space applications to assign Key IDs to physical pages. This kernel-level support provides the mappings that link individual sandboxes to their unique encryption keys and memory regions.
Demo / Proof of Concept
▶ Watch: TME-Box framework: compiler, allocator, kernel support (8:00)
While the presentation does not feature a live "demo" in the traditional sense, it details the implementation of a functional prototype and a comprehensive evaluation of its performance characteristics. The TME-Box prototype was built using the described LLVM compiler extension, a custom memory allocator, and necessary kernel support, demonstrating the feasibility and practicality of the TME-Box design.
The performance evaluation focused on identifying and quantifying the various sources of overhead introduced by TME-Box. The primary benchmark suite used was SPEC CPU 2017, a standard industry benchmark for measuring CPU-intensive workloads. The evaluation aimed to dissect where performance costs originated:
- Compiler Instrumentation: The vast majority of overhead stems from the compiler's need to instrument every memory operation to control the base address and index, thereby enforcing Key ID usage. This was optimized using x86 segment-based addressing (GS register mode). Additionally, control flow transfer instrumentation, particularly the software-based return address protection, was identified as a significant contributor to overhead. The speaker noted that this could be mitigated by leveraging hardware features like Intel CET shadow stack in the future.
- Memory Initialization: Setting up the MAC values for newly allocated memory pages introduces a certain overhead during initialization.
- Memory Encryption/Decryption: The inherent overhead of the TME-MK encryption engine itself. This was specifically measured using the LMBench suite, reporting a maximum latency overhead of 6.8 nanoseconds when data is served from DRAM.
- Memory Aliasing: Depending on how heavily two sandboxes share memory on the same physical page, there can be some overhead associated with managing these aliased regions.
The quantitative results are compelling. For the more performant GS mode (segment-based addressing), TME-Box reported a geometric mean overhead of 5.2% for data isolation and 9.7% for code and data isolation. In comparison, the R15 mode (general-purpose register) showed higher overheads of 13.4% for data isolation and 17.7% for code and data isolation, clearly indicating the performance benefits of segment-based addressing for this context. These figures underscore the efficiency of TME-Box, demonstrating that hardware-assisted in-process isolation can be achieved with a minimal performance footprint.
Defensive Implications
▶ Watch: Performance evaluation setup and overhead identification (9:00)
TME-Box introduces a paradigm shift in how developers and cloud providers can approach in-process security, offering robust, hardware-backed defenses against common memory safety vulnerabilities without sacrificing the performance advantages of in-process sandboxing.
For cloud providers, the adoption of TME-Box-like mechanisms on TME-MK-enabled x86 hardware presents a significant opportunity to enhance the security posture of multi-tenant environments. It allows for the co-location of multiple, potentially untrusted, cloud workers or components within a single process, each isolated by hardware-enforced encryption keys. This can effectively mitigate the risk of data leakage or corruption that arises from memory safety bugs (e.g., buffer overflows, use-after-free) within one component affecting sensitive data in another, reminiscent of past vulnerabilities like Heartbleed and Cloudbleed.
Developers building in-process sandboxes or highly optimized applications that handle sensitive data can leverage TME-Box to achieve fine-grained confidentiality and integrity. The ability to isolate memory down to the individual cache line provides an unprecedented level of control, allowing critical data structures, cryptographic keys, or authentication tokens to be protected with their own unique encryption keys, even if they reside on the same physical page as less sensitive data. This granular isolation means that even if an attacker manages to compromise a part of the sandbox, the damage is contained to the specific, unprotected memory regions, rather than the entire process's memory space.
Furthermore, TME-Box's hardware-assisted integrity checks offer an immediate and robust detection mechanism for unauthorized memory access or tampering. Any attempt by a compromised sandbox to read or write to memory belonging to another sandbox will trigger a hardware exception, alerting defenders to a security breach instantly. This proactive detection capability is invaluable for incident response.
The framework also encourages the development of more secure memory allocators and compilers. The need for a custom allocator that correctly initializes memory with Key IDs and compiler instrumentation that enforces memory boundaries pushes the ecosystem towards more security-aware software development practices. Organizations should consider integrating TME-Box's principles into their security architectures, particularly for high-value assets and sensitive data processing, to achieve a strong blend of performance and hardware-backed security.
Key Takeaways
- TME-Box repurposes Intel TME-MK to provide hardware-assisted, in-process isolation on commodity x86 processors.
- It offers scalable and fine-grained memory isolation, from individual cache lines to full pages, using page aliasing and designated encryption keys.
- The system provides both confidentiality (AES XTS encryption) and integrity (SHA-3 MAC), with hardware-level detection of unauthorized memory access via MAC mismatches.
- TME-Box can isolate up to 32,000 sandboxes through encryption keys, making it suitable for multi-tenant cloud environments.
- A prototype demonstrates low performance overheads: 5.2% for data isolation and 9.7% for code and data isolation in GS mode.
- The framework consists of an LLVM compiler extension, a custom memory allocator, and kernel support to manage Key IDs and enforce memory boundaries.
About the Speaker(s)
Martin Unterguggenberger is the presenter of "TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption" at the NDSS Symposium. His work focuses on addressing the challenges of lightweight and efficient isolation in modern cloud settings by leveraging innovative hardware features.
Reviews
Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT
Solid systems security research that finds genuinely clever repurposing of a hardware primitive most people associate with confidential computing, not intra-process sandboxing. The cache-line granularity through page aliasing is the kind of insight that makes you stop and re-read it — TME-MK's authenticated encryption MACs are per-cache-line, not per-page, and exploiting that gap to get sub-page isolation without new hardware is legitimately non-obvious. Overheads are credible and the threat model (Heartbleed-class bugs in co-tenant in-process workers) is realistic and pressing.
Heather Calloway (CISO) — WEAK
Technically credible systems research on hardware-assisted in-process isolation, but the presentation never climbs out of the architecture layer to reach anyone who makes decisions. The cloud security problem it addresses is real; the bridge from research to deployment, governance, or organizational action is essentially absent.
→ Top-rated talks at Network and Distributed System Security (NDSS) Symposium 2025
All talks from Network and Distributed System Security (NDSS) Symposium 2025