The Rust programming language enforces three basic Rust principles, namely ownership, borrowing, and AXM (Aliasing Xor Mutability) to prevent security bugs such as memory safety violations and data races. However, Rust projects often have mixed code, i.e., code that also uses unsafe Rust, FFI (Foreign Function Interfaces), and inline assembly for low-level control. The Rust compiler is unable to statically enforce Rust principles in mixed Rust code which can lead to many security vulnerabilities. In this paper, we propose CapsLock, a security enforcement mechanism that can run at the level of machine code and detect Rust principle violations at run-time in mixed code. CapsLock is kept simple enough to be implemented into recent capability-based hardware abstractions that provide low-cost spatial memory safety. CapsLock introduces a novel revoke-on-use abstraction for capability-based designs, wherein accessing a memory object via a capability implicitly invalidates certain other capabilities pointing to it, thereby also providing temporal memory safety automatically, without requiring software to explicitly specify such invalidation. Thus, CapsLock is the first mechanism capable of providing cross-language enforcement of Rust principles. We implemented a prototype of CapsLock on QEMU. Evaluation results show that CapsLock is highly compatible with existing Rust code (passing 99.7% of the built-in test cases of the 100 most popular crates) and flags Rust principle violations in real-world Rust projects that use FFI or inline assembly. We discovered 8 previously unknown bugs in such crates in our experiments.

Hardware capabilities offer an alternative to how access control is commonly implemented in processors today, i.e., through enforcement of permission checks on virtual memory at the time of address translation. Despite conceptual strengths of capability hardware, it is challenging for existing capability-oblivious software stacks to be compatible with capability hardware and to interoperate with capability-aware software, hindering faster adoption. Prior attempts to achieve this sacrifice the inherent advantages of capabilities. They require trusting a software central authority (e.g., the OS kernel) for capability-based isolation and limit the scope of capability-based memory sharing to individual virtual address spaces. This paper proposes the idea of caplification, a novel mechanism to enable seamless co-existence of capability-aware and capability-oblivious software stacks. We concretely implement our proposed idea on a modern RISC-V capability hardware and show how it enables running a commodity unmodified (or capability-oblivious) Linux OS. Our design retains the full advantages provided by hardware capabilities, such as creating fine-grained hardware-isolated memory compartments both in user- and kernel-space. We evaluated our prototype system both on QEMU emulation and on hardware RTL simulation. We find that the performance of our system is comparable to prior baseline designs, while offering cost improvements in scenarios of secure data sharing.

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?