CAPSTONE
Capability-based Foundations for Trustless Secure Memory Access
The traditional hardware-based approach to security problems such as memory safety and memory isolation has been individual ad hoc architectural extensions. This has created a fragmented landscape: the protection mechanisms are not universally available, and the interactions between different extensions are unclear or confusing. In part, this problem is due to the traditional virtual-memory-based access control model, which imposes a rigid central and hierarchical trust model and coarse protection granularity.
The CAPSTONE project aims to design a computer architecture expressive enough to cover multiple security goals with a single clean set of primitives. We take an approach based on capability-based security, where the hardware enforces security policies that are not controlled by a central trusted authority, but collectively defined by different software components.
Topics that this project explores include:
-
Isolation with zero software TCB (Trusted Computing Base): In general, compared with hardware, software is complex, buggy and easy to compromise. The recent surge in public interests in trusted execution environments (TEEs) and confidential computing has recognised this issue, and reducing the software TCB has been a pressing need in various contexts ranging from cloud services to edge devices. Prior work has attempted to extend existing virtual-memory-based architectures for such a goal. In CAPSTONE, we seek to provide a more principled capability-based approach.
-
Unifying memory isolation and memory safety: Memory isolation and memory safety have traditionally been treated separately and supported using disjoint sets of mechanisms. Capabilities, which bind access permissions to resource references, provide a basis for unifying those two goals. We seek to answer the question of how isolation semantics maps to program semantics so both can be supported with a single mechanism, despite the apparently different threat models in the two use cases. In particular, we are interested in enforcing temporal memory safety and higher-level safety properties (e.g., data race prevention) with capabilities.
-
Bridging capabilities and traditional virtual-memory-based systems: Capability-based systems are very different from the ubiquitous virtual-memory-based systems, and a naive design either compromises the strengths of capabilities, or requires extensive changes in software. We aim to design a capability-based system that interoperates well with existing software stacks while maintaining the advantages of capabilities.
-
Efficient implementation of capability-based architectures: We also explore the techniques to efficiently implement such next-generation architectures in hardware.
For more information, please visit the dedicate CAPSTONE website.
TEEs
Trusted execution environments (TEEs) isolate user-space applications into secure enclaves without trusting the OS. Existing TEE memory models are rigid -- they do not allow an enclave to share memory with other enclaves. This lack of essential functionality breaks compatibility with several constructs such as shared memory, pipes, and fast mutexes that are frequently required in data intensive use-cases. In this work, we present Elasticlave, a new TEE memory model which allows sharing. Elasticlave strikes a balance between security and flexibility in managing access permissions. Our implementation of Elasticlave on RISC-V achieves performance overheads of about 10% compared to native (non-TEE) execution for data sharing workloads. In contrast, a similarly secure implementation on a rigid TEE design incurs 1-2 orders of magnitude overheads for these workloads. Thus, Elasticlave enables cross-enclave data sharing with much better performance.
Exceptions are a commodity hardware functionality which is central to multi-tasking OSes as well as event-driven user applications. Normally, the OS assists the user application by lifting the semantics of exceptions received from hardware to program-friendly user signals and exception handling interfaces. However, can exception handlers work securely in user enclaves, such as those enabled by Intel SGX, where the OS is not trusted by the enclave code? In this paper, we introduce a new attack called SmashEx which exploits the OS-enclave interface for asynchronous exceptions in SGX. It demonstrates the importance of a fundamental property of safe atomic execution that is required on this interface. In the absence of atomicity, we show that asynchronous exception handling in SGX enclaves is complicated and prone to re-entrancy vulnerabilities. Our attacks do not assume any memory errors in the enclave code, side channels, or application-specific logic flaws. We concretely demonstrate exploits that cause arbitrary disclosure of enclave private memory and code-reuse (ROP) attacks in the enclave. We show reliable exploits on two widely-used SGX runtimes, Intel SGX SDK and Microsoft Open Enclave, running OpenSSL and cURL libraries respectively. We tested a total of 14 frameworks, including Intel SGX SDK and Microsoft Open Enclave, 10 of which are vulnerable. We discuss how the vulnerability manifests on both SGX1-based and SGX2-based platforms. We present potential mitigation and long-term defenses for SmashEx.
Memory Safety
OS Security
Capability-based memory isolation is a promising new architectural primitive. Software can access low-level memory only via capability handles rather than raw pointers, which provides a natural interface to enforce security restrictions. Existing architectural capability designs such as CHERI provide spatial safety, but fail to extend to other memory models that security-sensitive software designs may desire. In this paper, we propose Capstone, a more expressive architectural capability design that supports multiple existing memory isolation models in a trustless setup, i.e., without relying on trusted software components. We show how Capstone is well-suited for environments where privilege boundaries are fluid (dynamically extensible), memory sharing/delegation are desired both temporally and spatially, and where such needs are to be balanced with availability concerns. Capstone can also be implemented efficiently. We present an implementation sketch and through evaluation show that its overhead is below 50% in common use cases. We also prototype a functional emulator for Capstone and use it to demonstrate the runnable implementations of six real-world memory models without trusted software components: three types of enclave-based TEEs, a thread scheduler, a memory allocator, and Rust-style memory safety—all within the interface of Capstone.
Exceptions are a commodity hardware functionality which is central to multi-tasking OSes as well as event-driven user applications. Normally, the OS assists the user application by lifting the semantics of exceptions received from hardware to program-friendly user signals and exception handling interfaces. However, can exception handlers work securely in user enclaves, such as those enabled by Intel SGX, where the OS is not trusted by the enclave code? In this paper, we introduce a new attack called SmashEx which exploits the OS-enclave interface for asynchronous exceptions in SGX. It demonstrates the importance of a fundamental property of safe atomic execution that is required on this interface. In the absence of atomicity, we show that asynchronous exception handling in SGX enclaves is complicated and prone to re-entrancy vulnerabilities. Our attacks do not assume any memory errors in the enclave code, side channels, or application-specific logic flaws. We concretely demonstrate exploits that cause arbitrary disclosure of enclave private memory and code-reuse (ROP) attacks in the enclave. We show reliable exploits on two widely-used SGX runtimes, Intel SGX SDK and Microsoft Open Enclave, running OpenSSL and cURL libraries respectively. We tested a total of 14 frameworks, including Intel SGX SDK and Microsoft Open Enclave, 10 of which are vulnerable. We discuss how the vulnerability manifests on both SGX1-based and SGX2-based platforms. We present potential mitigation and long-term defenses for SmashEx.