Blindfold: Confidential Memory Management by Untrusted Operating System

Blindfold: Confidential Memory Management by Untrusted Operating System

Speakers: Caihua Li

Conference: NDSS Symposium

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

Overview

In an era where operating systems (OS) are increasingly complex and prone to vulnerabilities, the security of sensitive application data stored in memory remains a critical concern. The talk "Blindfold: Confidential Memory Management by Untrusted Operating System" by Caihua Li addresses this fundamental challenge, proposing a novel architecture that allows an untrusted OS to manage memory without ever directly accessing or knowing the values of sensitive user data. This work is crucial because traditional OS designs, like Linux, possess excessive access capabilities, making them a prime target for attackers seeking to exfiltrate passwords, cryptographic keys, and other confidential information directly from memory if the OS itself is compromised.

Blindfold re-architects the interaction between the OS and user space memory by classifying memory access into two distinct categories: semantic and non-semantic. By carefully mediating and regulating these interactions through a minimal Trusted Computing Base (TCB), Blindfold ensures that the OS can perform essential tasks like paging, swapping, and memory movement efficiently, all while maintaining the confidentiality of user data. This approach offers a significant leap forward in system security, providing a robust defense against OS-level compromises and redefining the trust boundaries in modern computing environments.

Background

▶ Watch: Problem: Untrusted OS has excessive memory access (0:50)

The pervasive insecurity of traditional operating systems stems from several inherent characteristics. Modern OS kernels, such as Linux, are characterized by their immense complexity, often comprising millions of lines of code. This large code base inherently translates to a vast attack surface, increasing the likelihood of undiscovered vulnerabilities. Furthermore, these kernels are typically written in unsafe languages like C, which are prone to memory safety issues, and are rarely formally certified for security. Consequently, a compromised OS grants an attacker unfettered access to all application data residing in memory, including highly sensitive information like passwords and encryption keys.

The fundamental problem, as identified by the Blindfold researchers, is that the OS possesses far more access capability than it genuinely requires for its core functions. While the OS must manage hardware resources like CPU and memory, it often doesn't need to know the exact value of the data it's manipulating. For instance, when the OS moves pages in memory, it merely copies data from one physical frame to another; the specific content of those pages is irrelevant to the operation itself. This observation led to the crucial distinction between two types of OS memory access:

1. Non-semantic access: The OS does not care about the value of the data. Examples include paging, page migration, and certain data movement operations where the OS acts as a mere conduit or manager of physical resources.
2. Semantic access: The OS does require the value of the data to fulfill its job. This typically occurs for system call parameters (e.g., a pathname in an open system call) or during signal handling, where the kernel needs to interpret or modify specific data structures.

Traditional OS designs directly access user space memory for both semantic and non-semantic operations. While this is efficient, it is inherently insecure. Previous attempts to mitigate this insecurity primarily fell into two categories:

• Encrypted Views: Some approaches provide the OS with an encrypted view of user memory. While secure, encryption and decryption operations are computationally expensive, leading to significant performance overhead.
• Hidden Pages: Other methods completely hide sensitive user pages from the OS. This secures the data but prevents the OS from performing critical optimizations and management tasks on these hidden pages, rendering the system inefficient or non-functional for those protected regions.

Moreover, supporting semantic access in previous work often involved copying system call parameters to dedicated buffers. This required complex, case-by-case handling for different system calls or signal handling, leading to a large and complex Trusted Computing Base (TCB), which defeats the purpose of minimizing trusted components. Blindfold aims to overcome these limitations by providing a universal, efficient, and secure mechanism for both types of memory access.

Key Findings

▶ Watch: Limitations and inefficiencies of prior solutions (3:20)

Blindfold's core contribution is its ability to enable an untrusted operating system to manage confidential user memory effectively, without ever gaining direct access to the sensitive data within it. This is achieved through a radical re-imagination of how the OS interacts with user space, underpinned by two key design components that differentiate it from prior work.

Firstly, Blindfold fundamentally alters how the OS accesses user space data. Instead of direct access, the OS delegates memory operations to a small, secure Trusted Computing Base (TCB). For operations like page movement, the OS instructs the TCB to perform the action on its behalf. The TCB then encrypts pages only when necessary, such as during I/O operations or swapping to persistent storage. This selective encryption approach avoids the performance penalties associated with pervasive encryption while ensuring data confidentiality when it leaves volatile memory. This design allows the OS to continue its management functions (like optimizing memory layout) without ever seeing the sensitive contents of the pages.

Secondly, Blindfold introduces a universal and lightweight capability system to regulate the OS's semantic access. Every system call and exception is trapped into the TCB, which then creates and manages capabilities—fine-grained permissions that dictate what the OS can access and how. When the kernel needs to copy data between user space and kernel space (e.g., using copy_from_user), this low-level interface is mediated by the TCB. The TCB checks the relevant capabilities before permitting the data transfer, ensuring that the OS only accesses data it's explicitly allowed to, and only in a way that respects confidentiality. This universal mechanism eliminates the need for complex, case-by-case handling of semantic access, significantly reducing the complexity and size of the TCB.

These two design components, coupled with an innovative isolation mechanism based on page table mediation, form the bedrock of Blindfold. They allow the system to achieve strong confidentiality guarantees against a compromised OS, maintain OS functionality and performance optimizations, and keep the TCB minimal, thereby enhancing overall system security.

Technical Deep Dive

▶ Watch: Blindfold's design for non-semantic memory access (4:50)

Blindfold's architecture is meticulously designed around mediating and controlling the operating system's access to user memory, distinguishing between semantic and non-semantic operations, and enforcing these policies through a robust isolation mechanism.

Regulating User Space Access

Non-semantic Access: For operations where the OS does not need to understand the data's value (e.g., moving pages, paging, page migration), Blindfold employs an indirect access model. The untrusted OS does not directly manipulate the user data within pages. Instead, when the OS needs to perform a non-semantic operation like moving a page from one physical frame to another, it makes a request to the Trusted Computing Base (TCB). The TCB then executes the page movement on behalf of the OS. A critical optimization here is that the TCB only encrypts pages when strictly necessary, such as during I/O operations or swapping to disk. This means that for typical in-memory page movements, the data remains unencrypted within the physical memory, allowing for efficient operations. The OS can still "manage" these pages (e.g., decide where to move them) but cannot inspect their contents, as the TCB acts as a blind custodian, moving opaque blocks of data.

Semantic Access: For operations where the OS does need to access the value of data (e.g., system call parameters like a file path, or data during signal handling), Blindfold introduces a lightweight capability system.

1. System Call and Exception Trapping: Every system call and exception from user space is trapped into the TCB. This allows the TCB to intercept all potential interactions where the OS might need to access user data.
2. Capability Creation: Upon trapping, the TCB analyzes the system call or exception context and creates appropriate capabilities. These capabilities are fine-grained permissions that specify what data the OS can access, how it can access it (e.g., read-only), and for how long.
3. Low-Level Kernel Function Mediation: The key to enforcing these capabilities lies in mediating low-level kernel functions that transfer data between user and kernel space. Specifically, Blindfold mediates functions like copy_from_user and copy_to_user. Whenever the kernel calls copy_from_user to retrieve data from user space (e.g., a system call parameter), the TCB is invoked. The TCB checks if the OS possesses the necessary capabilities for that specific memory region and access type before allowing the data transfer. This approach makes the capability system universal, avoiding the complex, case-by-case handling that plagued previous solutions and keeping the TCB small.

Isolation Mechanism: Page Table Mediation

The second key design component is Blindfold's robust isolation mechanism, which significantly differs from previous work that often leveraged nested virtualization or nested paging. These prior approaches typically required the TCB to manage and switch between multiple nested page tables, increasing TCB size and complexity.

Blindfold instead employs mediation for page table updates from the operating system.

1. Read-Only Page Tables: The core principle is that all page tables are made read-only for the untrusted operating system. This means the OS cannot directly modify the virtual-to-physical memory mappings.
2. Mediated Updates: When the OS needs to update a page table (e.g., to map new memory, unmap pages, or change permissions), it must make a special system call to the TCB. In the implementation, this involves mediating the set_PTE function (Page Table Entry). Every page table update therefore invokes the TCB.
3. TCB Monitoring: While the page tables themselves are outside the TCB (i.e., they reside in regular memory that the OS can see but not modify directly), the TCB continuously monitors all updates. This allows the TCB to maintain a complete and accurate understanding of the entire virtual-to-physical memory mapping without having to manage the memory itself.

This design offers several significant advantages:

• Small TCB: The TCB's role is primarily to monitor and mediate page table updates, not to manage memory directly. This keeps the TCB significantly smaller and simpler, reducing its own attack surface.
• Portability: This design is highly portable across popular architectures. It only requires a higher privilege level and an MMU (Memory Management Unit). It does not necessitate complex hardware features like nested paging, which are not universally available or efficiently implemented.

Higher Privilege Layer and Comparison to Nested Kernel

During the Q&A, the speaker clarified the nature of the "higher privilege level." For their prototype on ARMv8 (ARM VA), this refers to the EL3 (Exception Level 3), also known as monitor mode. This is a hardware-provided privilege level above the user mode (EL0) and kernel mode (EL1). The Blindfold TCB, which they refer to as "guardian," runs at this highest privilege level, allowing it to intercept and mediate all OS actions, including page table updates.

The speaker also addressed a comparison to the "Nested Kernel" paper from 2015. While both share the technique of relying on higher privilege software (or hardware-provided levels) for mediation, they have different goals:

• Nested Kernel: Aims to protect the kernel itself from internal vulnerabilities or malicious modules. It operates within the same hardware privilege level as the kernel, treating mediation as a function call, thus incurring lower overhead for such operations.
• Blindfold: Aims to protect user applications from a completely untrusted kernel. This requires a stronger isolation boundary, hence the use of a distinct, higher hardware privilege level like EL3. The speaker acknowledged that trapping into EL3 does incur higher overhead compared to intra-kernel privilege isolation.

However, the speaker emphasized that Blindfold's design is portable. While their prototype uses ARMv8's EL3, the concept of a higher privilege layer can also be provided by software solutions, similar to how Nested Kernel operates within x86 architectures without a dedicated EL3 equivalent. This implies that Blindfold's core principles could be implemented on x86 platforms using software-based privilege isolation techniques, albeit with careful consideration of the performance implications of the chosen isolation mechanism.

In essence, Blindfold presents a robust and flexible architecture that fundamentally redefines the trust model between the OS and application data, leveraging minimal trusted components and portable hardware features to achieve strong confidentiality guarantees.

Demo / Proof of Concept

▶ Watch: Blindfold's isolation mechanism: Read-only page tables (7:50)

While the talk did not feature a live, interactive demonstration in the traditional sense, the authors provided compelling evaluation results that serve as the proof of concept for Blindfold's efficacy and performance characteristics. All evaluations were conducted on a Raspberry Pi 4 Model B, a common and accessible ARM-based platform, underscoring the portability claims of the design.

The evaluation focused on assessing the overhead introduced by Blindfold's two main modules: user memory access mediation and system call/page table update mediation.

1. Memory Throughput (eron bench): For applications primarily accessing their own memory (which represents the most common use case), Blindfold demonstrated little overhead. This applies to both sensitive and non-sensitive applications, indicating that the design successfully avoids significant performance penalties for typical application execution where direct OS intervention in memory management isn't constantly required.

1. Memory-Intensive Applications (Redis): Applications that frequently trigger memory paging, such as the in-memory data store Redis, experienced a 10% to 20% overhead. This overhead is directly attributed to the necessity of trapping all page table updates into the TCB. Since Redis makes extensive use of memory and thus frequently modifies its memory mappings, the mediation of set_PTE calls becomes a bottleneck.

1. I/O-Intensive Applications (Nginx): For applications with high I/O demands, like the web server Nginx, the overhead was even higher, typically around 18%. This is primarily due to the large number of system calls involved in I/O operations. Each system call potentially triggers TCB mediation for semantic access regulation and capability checks, leading to a measurable performance impact.

The evaluation results confirm that Blindfold successfully maintains confidentiality with acceptable performance trade-offs, particularly for memory-intensive and I/O-intensive workloads where the mediation mechanisms are frequently invoked. The "little overhead" for common applications suggests that for the majority of use cases, the security benefits outweigh the performance cost.

Defensive Implications

▶ Watch: Performance evaluation results and overhead analysis (10:00)

Blindfold's approach to confidential memory management has profound defensive implications for securing modern computing systems, particularly against sophisticated adversaries capable of compromising the operating system itself.

Firstly, Blindfold fundamentally shifts the security boundary. By ensuring that a compromised OS cannot directly access the contents of user memory, it transforms the OS from a single point of failure into a less privileged entity. This means that even if an attacker gains full control over the kernel, they cannot automatically exfiltrate sensitive data like cryptographic keys, passwords, or intellectual property stored in application memory. This dramatically raises the bar for attackers, forcing them to find vulnerabilities not just in the OS, but specifically within the small, highly scrutinized Trusted Computing Base (TCB), which has a significantly smaller attack surface.

Secondly, the distinction between semantic and non-semantic access provides a blueprint for designing more secure kernels and hardware. Future OS designs could incorporate similar principles, where default memory access is non-semantic and value-based access is strictly mediated and capability-driven. Hardware architects could also draw inspiration to develop more granular memory protection units that natively support such access distinctions and mediation mechanisms, potentially reducing the overhead observed in software-only implementations.

Thirdly, Blindfold's portability, requiring only a higher privilege level (like ARM's EL3 or software equivalents) and an MMU, makes it applicable to a wide range of platforms, from embedded systems to cloud environments. In cloud computing, where tenants often run on virtual machines managed by a cloud provider's potentially untrusted hypervisor/OS stack, Blindfold could offer an additional layer of confidentiality for sensitive workloads. It provides a strong foundation for building secure enclaves or confidential computing solutions that are robust against OS-level attacks.

Finally, the detailed performance analysis provides defenders with concrete data to assess the trade-offs. For applications handling highly sensitive data where confidentiality is paramount (e.g., financial transactions, medical records, classified information), the overheads of 10-20% for memory-intensive tasks and ~18% for I/O-intensive tasks might be entirely acceptable in exchange for the enhanced security. Organizations can use this information to make informed decisions about deploying such architectures for critical workloads.

Key Takeaways

• Traditional operating systems (like Linux) are inherently untrustworthy due to their complex codebases, large attack surfaces, and use of unsafe languages, making them vulnerable to attacks that can steal sensitive application data from memory.
• Blindfold is a novel architecture that enables an untrusted OS to manage memory without ever directly accessing or knowing the values of confidential user data.
• It distinguishes between non-semantic access (OS doesn't need data value, e.g., paging) and semantic access (OS needs data value, e.g., system call parameters).
• For non-semantic access, the OS delegates page movement to a Trusted Computing Base (TCB), which only encrypts pages when strictly necessary (e.g., I/O, swapping), avoiding constant encryption overhead.
• For semantic access, Blindfold uses a lightweight capability system that traps all system calls and exceptions into the TCB, mediating low-level kernel functions like copy_from_user to enforce access policies.
• Isolation is achieved through page table mediation, where OS page tables are read-only, and all updates are mediated by the TCB, keeping the TCB small and the design portable (requiring only an MMU and a higher privilege level like ARM's EL3).
• Evaluated on a Raspberry Pi 4 Model B, Blindfold shows minimal overhead for common applications, but introduces 10-20% overhead for memory-intensive applications like Redis (due to frequent page table updates) and ~18% for I/O-intensive applications like Nginx (due to numerous system calls).

About the Speaker(s)

Caihua Li is the speaker who presented the "Blindfold: Confidential Memory Management by Untrusted Operating System" talk at the NDSS Symposium. The transcript identifies him by his first name, Taiwi, during the introduction.