CODOMs: Protecting software with Code-centric memory Domains

Vilanova, Lluís; Ben-Yehuda, Muli; Navarro, Nacho; Etsion, Yoav; Valero, Mateo

doi:10.1109/isca.2014.6853202

Cited by 24 publications

(36 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Hardware-supported capability systems like CAP [47], StarOS [32], and IBM System/38 [24] extend the ISA with special instructions and registers allowing hardware to enforce protection for even small objects without mediation of a trusted entity. Other systems proposing hardware capabilities include the M-Machine [12] (adopting a capability system without compatibility requirements), CHERI [62] (retaining compatibility with capability-unaware code), and CODOMs [58] (focusing on hardware support for isolation between components).…”

Section: Capability Systemsmentioning

confidence: 99%

“…Although capabilities were proven to be a useful concept, many previously proposed hardware implementations were based on the use of Instruction-Set Architecture (ISA) extensions. Unfortunately, extending the ISA of a processor is not an easy task, and the long delay between introducing the concept and the implementation of new ISA features hampers the adoption of schemes that rely on ISA support, such as CHERI [13,62] or CODOMS [58]. It can easily take more than 5 years from conception to market introduction, delaying the impact and reducing the commercial interest.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Memory-Side Protection With a Capability Enforcement Co-Processor

Azriel

Humbel

Achermann

et al. 2019

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

Byte-addressable nonvolatile memory (NVM) blends the concepts of storage and memory and can radically improve data-centric applications, from in-memory databases to graph processing. By enabling large-capacity devices to be shared across multiple computing elements, fabric-attached NVM changes the nature of rackscale systems and enables short-latency direct memory access while retaining data persistence properties and simplifying the software stack. An adequate protection scheme is paramount when addressing shared and persistent memory, but mechanisms that rely on virtual memory paging suffer from the tension between performance (pushing toward large pages) and protection granularity (pushing toward small pages). To address this tension, capabilities are worth revisiting as a more powerful protection mechanism, but the long time needed to introduce new CPU features hampers the adoption of schemes that rely on instruction-set architecture support. This article proposes the Capability Enforcement Co-Processor (CEP), a programmable memory controller that implements fine-grain protection through the capability model without requiring instruction-set support in the application CPU. CEP decouples capabilities from the application CPU instruction-set architecture, shortens time to adoption, and can rapidly evolve to embrace new persistent memory technologies, from NVDIMMs to native NVM devices, either locally connected or fabric attached in rack-scale configurations. CEP exposes an application interface based on memory handles that get internally converted to extendedpointer capabilities. This article presents a proof of concept implementation of a distributed object store (Redis) with CEP. It also demonstrates a capability-enhanced file system (FUSE) implementation using CEP. Our proof of concept shows that CEP provides fine-grain protection while enabling direct memory access from application clients L. Azriel and L. Humbel made equal contributions.

show abstract

Section: Capability Systemsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Memory-Side Protection With a Capability Enforcement Co-Processor

Azriel

Humbel

Achermann

et al. 2019

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

show abstract

“…In some sense, CrossOver can be viewed as a hardware extension providing a new capability of cross-world call which supports up-level software to implement authorization and provide various services across worlds without the intervention of other privileged software to improve performance. CODOMs [39] provides efficient protection among multiple software components that share the same address space in a capability manner, while CrossOver allows secure, efficient and flexible cross-world calls across multiple layers not only within the same address space, but also across multiple address spaces.…”

Section: Related Workmentioning

confidence: 99%

Reducing world switches in virtualized environment with flexible cross-world calls

Xia

Chen

et al. 2015

Proceedings of the 42nd Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

Modern computers are built with increasingly complex software stack crossing multiple layers (i.e., worlds), where crossworld call has been a necessity for various important purposes like security, reliability, and reduced complexity. Unfortunately, there is currently limited cross-world call support (e.g., syscall, vmcall), and thus other calls need to be emulated by detouring multiple times to the privileged software layer (i.e., OS kernel and hypervisor). This causes not only significant performance degradation, but also unnecessary implementation complexity.This paper argues that it is time to rethink the design of traditional cross-world call mechanisms by reviewing existing systems built upon hypervisors. Following the design philosophy of separating authentication from authorization, this paper advocates decoupling of the authorization on whether a world call is permitted (by software) from unforgeable identification of calling peers (by hardware). This results in a flexible cross-world call scheme (namely CrossOver) that allows secure, efficient and flexible cross-world calls across multiple layers not only within the same address space, but also across multiple address spaces. We demonstrate that CrossOver can be approximated by using existing hardware mechanism (namely VMFUNC) and a trivial modification of the VMFUNC mechanism can provide a full support of CrossOver. To show its usefulness, we have conducted case studies by using several recent systems such as Proxos, HyperShell, Tahoma and ShadowContext. Performance measurements using full-system emulation and a real processor with VMFUNC shows that CrossOver significantly boosts the performance of the mentioned systems.

show abstract

“…This paper presents direct IPC (dIPC), an OS extension that leverages the recent CODOMs architecture [61] to marry the isolation of processes with the performance of synchronous function calls. dIPC enables threads in one process to call a function on another process, delivering the same performance as if the two were a single composite application, but without compromising their isolation.…”

Section: Introductionmentioning

confidence: 99%

“…dIPC builds on top of the CODOMs architecture [61], which was designed to isolate software components inside a single process while enabling inter-component function calls at negligible overheads. dIPC repurposes CODOMs to isolate multiple processes on a shared page table to achieve low-overhead and secure inter-process function calls.…”

Section: Introductionmentioning

confidence: 99%

Direct Inter-Process Communication (dIPC)

Vilanova

Jordà

Navarro

et al. 2017

Proceedings of the Twelfth European Conference on Computer Systems

Self Cite

View full text Add to dashboard Cite

In current architectures, page tables are the fundamental mechanism that allows contemporary OSs to isolate user processes, binding each thread to a specific page table. A thread cannot therefore directly call another process's function or access its data; instead, the OS kernel provides data communication primitives and mediates process synchronization through inter-process communication (IPC) channels, which impede system performance. Alternatively, the recently proposed CODOMs architecture provides memory protection across software modules. Threads can cross module protection boundaries inside the same process using simple procedure calls, while preserving memory isolation. We present dIPC (for "direct IPC"), an OS extension that repurposes and extends the CODOMs architecture to allow threads to cross process boundaries. It maps processes into a shared address space, and eliminates the OS kernel from the critical path of inter-process communication. dIPC is 64.12× faster than local remote procedure calls (RPCs), and 8.87× faster than IPC in the L4 microkernel. We show that applying dIPC to a multi-tier OLTP web server improves performance by up to 5.12× (2.13× on average), and reaches over 94% of the ideal system efficiency.

show abstract

CODOMs: Protecting software with Code-centric memory Domains

Cited by 24 publications

References 16 publications

Memory-Side Protection With a Capability Enforcement Co-Processor

Memory-Side Protection With a Capability Enforcement Co-Processor

Reducing world switches in virtualized environment with flexible cross-world calls

Direct Inter-Process Communication (dIPC)

Contact Info

Product

Resources

About