CHERI Concentrate: Practical Compressed Capabilities

Abstract

We present CHERI Concentrate, a new fat-pointer compression scheme applied to CHERI, the most developed capability-pointer system at present. Capability fat pointers are a primary candidate to enforce fine-grained and non-bypassable security properties in future computer systems, although increased pointer size can severely affect performance. Thus, several proposals for capability compression have been suggested elsewhere that do not support legacy instruction sets, ignore features critical to the existing software base, and also introduce design inefficiencies to RISC-style processor pipelines. CHERI Concentrate improves on the state-of-the-art region-encoding efficiency, solves important pipeline problems, and eases semantic restrictions of compressed encoding, allowing it to protect a full legacy software stack. We present the first quantitative analysis of compiled capability code, which we use to guide the design of the encoding format. We analyze and extend logic from the open-source CHERI prototype processor design on FPGA to demonstrate encoding efficiency, minimize delay of pointer arithmetic, and eliminate additional load-to-use delay. To verify correctness of our proposed high-performance logic, we present a HOL4 machine-checked proof of the decode and pointer-modify operations. Finally, we measure a 50% to 75% reduction in L2 misses for many compiled C-language benchmarks running under a commodity operating system using compressed 128-bit and 64-bit formats, demonstrating both compatibility with and increased performance over the uncompressed, 256-bit format.

Capability Boehm: challenges and opportunities for garbage collection with capability hardware

“…CHERI Concentrate [15] is an elegant capability compression scheme that reduces the footprint of a capability value to 128 bits. However this shrinkage comes at the cost of some loss of precision in terms of representable base addresses 1 if (cheri_gettag(limit) == 0) { 2 limit -= ALIGNMENT; 3 } else { // ...…”

PACSan: Enforcing Memory Safety Based on ARM PA

“…When the object's size is large enough, this approach may have false positives or excessive performance overheads. Many efforts [11,29,44,45] embed metadata into pointers and implement different forms of fat pointers by extending registers or language implementations. However, the approach needs to change the processor hardware and increases runtime overheads.…”

Rigorous engineering for hardware security: Formal modelling and proof in the CHERI design and implementation process

“…Then there is a Bluespec [11] FPGA hardware implementation of the architecture, and a software stack above it, adapting LLVM [12] and FreeBSD [13] to CHERI-MIPS. All this has involved extensive work on the interaction between the capability system and systems aspects of memory management (static and dynamic linking, process creation, context switching, page swapping and signal delivery) [14]; on the overhead of compiling pointers to capabilities [5], [15]; on compartmentalisation of legacy software [16]; and on the performance overhead of tagged memory [17] and protectiondomain switches [18]. The underlying ideas are portable, not MIPS-specific, and work is underway on experimental academic RISC-V and industrial Arm versions -the latter in a major project involving Arm and the UK Government [19], [20] to produce prototype silicon and a development board.…”

“…The 256-bit format includes a 64-bit virtual address, base, and length; permission bits, to execute, load, and store data, to load, store, seal, and unseal capabilities, to invoke sealed capabilities, and to store local capabilities; an is-sealed bit; and a 24-bit object type, used in sealing, unsealing, and invoking. The 128-bit format [15] compresses this, exploiting the redundancy from allocation alignment (the proofs later in this paper are about the 256bit version). In this example, the base and length, identifying the memory region that the capability is allowed to access, are those of the original x allocation.…”