L4 Pointer: Software Spatial Safety

• L4 Pointer is a software-based spatial safety mechanism that extends ordinary 64-bit pointers to 128-bit objects carrying inline metadata for both lower and upper bounds.
• It uses SIMD operations to atomically update the pointer and its bounds, performing branchless checks via canonical address rules to detect buffer overflows and underflows.
• Empirical results indicate an average runtime slowdown of 1.44× and memory overhead of 1.7×, offering a compelling tradeoff compared to both software-only and hardware-assisted schemes.

L4 Pointer is a software technique for spatial memory safety that extends an ordinary 64-bit pointer into a 128-bit pointer-like object carrying inline bounds metadata, while relying on SIMD operations and architectural address-validity checks rather than new hardware extensions. Its stated target is the detection of spatial violations such as buffer overflow and underflow in C/C++, and its design is motivated by the tradeoff between software-only schemes, which often incur expensive metadata handling and runtime checks, and hardware-assisted schemes, which are unavailable without specific hardware support (Mok et al., 2023).

1. Concept and design goals

L4 Pointer is positioned as a per-pointer bounds mechanism. Each pointer carries its own metadata, and pointer arithmetic updates that metadata together with the underlying address. The design goals described for the system are full upper- and lower-bound checking, atomic pointer-plus-metadata updates for multithread safety, avoidance of new ISA support, and deployability on commodity architectures that already provide SIMD facilities, particularly x86 and ARM (Mok et al., 2023).

The paper frames L4 Pointer against several pre-existing design families. Per-pointer schemes are described as precise, because they can track pointer-specific bounds, but expensive because metadata must be propagated on copies and pointer arithmetic. Per-object schemes are cheaper and often more compatible, but may lose precision, especially for subobjects. Tagged-pointer designs preserve 64-bit pointer size but have limited metadata capacity because they consume only spare address bits. Shadow-memory and bounds-table systems introduce metadata lookups and additional memory traffic. Hardware-assisted systems, including Intel MPX, ARM MTE, CHERI-like capabilities, and custom architectural fat pointers, are treated as effective in part but deployment-constrained. L4 Pointer is proposed as a software-only middle ground that keeps metadata inline in a widened pointer representation (Mok et al., 2023).

The protection scope is explicitly spatial rather than temporal. The paper targets out-of-bounds pointer arithmetic and dereference, including both overflow and underflow. It does not claim temporal safety, use-after-free protection, or a general defense against arbitrary memory corruption beyond spatial bounds violations (Mok et al., 2023).

2. Pointer representation and inline bounds metadata

The core representation is a consecutive 128-bit object whose lower 64 bits store the ordinary virtual address and whose upper 64 bits store two 32-bit metadata fields, one associated with the upper bound and one with the lower bound (Mok et al., 2023). The paper gives the bit slices as

$pointer_{[64]} = L4_{[128]}[0:63]$

$upper_{[32]} = L4_{[128]}[64:95]$

$lower_{[32]} = L4_{[128]}[96:127].$

Each 32-bit bound field uses 31 bits for a value and the most significant bit as a flag. The encoding is not based on storing absolute base and end addresses. Instead, it stores offset-related quantities designed so that the flag bit becomes set when arithmetic crosses a bound. For heap initialization after an allocation such as p = malloc(size);, the paper specifies

$pointer_{[64]} = returnOfMalloc_{[64]}$

$upper_{[32]} = (1<<32)_{[32]} - size_{[32]}$

$lower_{[32]} = 0.$

The accompanying explanation is that upper is initialized so that if an offset larger than size is added, the most significant bit becomes 1, while lower starts at zero so that a negative offset from the initial pointer also drives its most significant bit to 1 (Mok et al., 2023).

This representation doubles pointer width and therefore breaks ordinary ABI compatibility. The paper treats that as an explicit tradeoff. Internal transformed code uses the widened representation; function signatures, structure layouts, pointer arrays, and allocation sizes are rewritten accordingly. Where external libraries are called, transformed pointers are converted back to ordinary pointers (Mok et al., 2023).

3. Pointer arithmetic and branchless bounds checking

L4 Pointer’s central operational idea is that a single vector addition updates the true address and both metadata fields simultaneously. The paper’s transformed example expresses this by replicating the offset across the three logical components:

tmp += (index << 96) | (index << 64) | (index);

The intended effect is that the low 64-bit pointer field and both 32-bit metadata fields advance together under one SIMD operation, preserving alignment between address and bounds state (Mok et al., 2023).

Dereference performs an implicit bounds check by exploiting canonical-address rules. On x86-64, if a virtual address is not in canonical form, the MMU raises an exception. L4 Pointer extracts the most significant bits of the upper and lower metadata fields,

$$msb\_lower_{[32]} = lower_{[32]} \ AND \ (1<<31)_{[32]}$$

$$msb\_upper_{[32]} = upper_{[32]} \ AND \ (1<<31)_{[32]},$$

combines them, and ORs the result into bit 63 of the 64-bit pointer used for the actual memory access. If either flag bit is set, the resulting address becomes non-canonical and faults on dereference (Mok et al., 2023).

The paper emphasizes that this is a branchless check. Instead of emitting explicit compare-and-branch sequences around loads and stores, it propagates bounds state through arithmetic and lets hardware address validation turn a bounds violation into an exception. That choice is central to its performance argument. It also explains the dependence on canonical-address behavior: the design assumes architectural semantics in which malformed high bits cause a fault rather than being ignored (Mok et al., 2023).

A further consequence is that L4 Pointer reduces quantized metadata management to local arithmetic on the pointer itself. Unlike shadow-memory systems, dereference does not require a metadata lookup. Unlike tagged pointers, it has enough inline capacity to encode both upper and lower bounds. Unlike Delta Pointer, which the paper characterizes as only checking the upper bound, L4 Pointer uses the extra 64 bits to represent both directions (Mok et al., 2023).

4. Compiler transformation and execution model

The implementation is an LLVM pass that rewrites all pointer-typed variables into L4 Pointer types. The transformation is illustrated schematically as

$int* \ ptr \;\rightarrow\; L4_{<int*>} \ ptr.$

Arrays of pointers and pointers embedded in structures are transformed analogously, which implies cascading changes to structure size and to allocation-size computations passed to malloc and related routines (Mok et al., 2023).

Heap, stack, and global objects are all brought under this instrumentation strategy. For stack and globals, the compiler introduces an L4-typed indirect pointer so that accesses are routed through the same metadata-aware arithmetic and dereference machinery used for heap pointers. WLLVM is used to merge multiple source files into a single bitcode file so that transformed structure definitions remain consistent across compilation units (Mok et al., 2023).

On x86, the implementation uses the LLVM vector type \<2 x i64>, mapped to XMM registers. The paper gives a representative instruction sequence: $upper_{[32]} = L4_{[128]}[64:95]$0 and states that movaps and paddq are used instead of scalar mov and add to manipulate the widened pointer atomically. On ARM, the paper suggests \<4 x i32> rather than \<2 x i64> because SIMD atomicity depends on element width and alignment conditions. The article also notes an important caveat: the paper asserts multithread safety from atomic SIMD movement on Intel, but does not provide a rigorous architecture-level proof of that claim (Mok et al., 2023).

Interoperability is partial rather than transparent. Internal transformed code uses L4 pointers; external library calls are adapted by converting back to ordinary pointers. The paper does not specify a complete ABI for mixed instrumented and uninstrumented binaries, and it leaves many hard language-level corner cases only generally indicated rather than fully formalized, including pointer-integer casts, unions, inline assembly, varargs, and provenance-sensitive behavior (Mok et al., 2023).

5. Reported performance and empirical results

The evaluation uses six Olden programs, CoreMark, two MiBench programs, and three SIMD-oriented programs from llvm-test-suite. The headline result reported for the full system is about 1.44× average slowdown and 1.7× average memory overhead (Mok et al., 2023).

The paper states that the benchmark with the worst slowdown is mst from Olden, around 1.8×, and that as the number of vertices grows the overhead approaches 2×. The explanation given is that mst uses linked-list-like structures with multiple pointer fields, so widening and instrumenting every pointer amplifies both instruction count and memory footprint. Memory overhead for mst is reported to grow from about 2× toward 3× as input size increases, and CoreMark is also identified as relatively pointer-heavy (Mok et al., 2023).

The SIMD-conflict experiment is intended to show that XMM usage for L4 operations does not break programs that already use SIMD. On isamax, stepfft, and expandfft, the average runtime overhead is reported as 1.34× and the memory overhead as 1.46×, and the programs are said to have worked without conflict (Mok et al., 2023).

Metric	Reported value	Context
Average slowdown	1.44×	Overall benchmark suite
Average memory overhead	1.7×	Overall benchmark suite
Worst slowdown	around 1.8×	mst from Olden
SIMD runtime overhead	1.34×	isamax, stepfft, expandfft
SIMD memory overhead	1.46×	isamax, stepfft, expandfft

The paper situates these numbers relative to several prior systems. It reports 3.23× for FRAMER and 2.15× for EffectiveSan, and describes L4 Pointer’s 1.44× as favorable relative to those software-only full-check systems. It also reports that Delta Pointer has 1.3× runtime overhead, while average memory overhead for L4 Pointer is 1.7× compared with cited figures of about 3.37× for AddressSanitizer, 3.32× for MemorySanitizer, 1.23× for FRAMER, and 1.21× for In-Fat (Mok et al., 2023).

6. Limitations, scope, and comparative significance

The design’s principal limitations follow directly from its representation choice. Because pointer types widen to 128 bits, ordinary ABI compatibility is not preserved. Any transformed program must consistently use the new representation, and function signatures and structure layouts change. The whole-program LLVM transformation, use of WLLVM, and explicit handling of external libraries all point to deployment complexity rather than drop-in compatibility (Mok et al., 2023).

The paper is also explicit that the system addresses only spatial safety. Temporal errors such as dangling pointers and use-after-free are outside scope. Likewise, the semantics of many difficult C and C++ idioms are not treated in depth, including unions, pointer-int casts, inline assembly, varargs, and exact subobject semantics. A further architectural limitation is the dependence on canonical-address behavior; portability beyond systems with such invalid-address trapping is correspondingly limited (Mok et al., 2023).

The metadata fields are only 32 bits each, and the paper notes without a detailed treatment that this may implicitly assume offset ranges that fit within 32 bits. That suggests an implementation bias toward object extents and arithmetic patterns compatible with that bound representation. The concurrency argument is similarly qualified: the paper presents atomic pointer-plus-metadata updates as a major advantage over systems in which pointers and metadata are updated separately, but the atomicity claim is asserted more than formally established (Mok et al., 2023).

Within the design space of memory-safety mechanisms, L4 Pointer occupies a distinctive position. Compared with tagged pointers, it sacrifices pointer-size compatibility in exchange for enough metadata to encode both lower and upper bounds. Compared with shadow-memory approaches, it avoids metadata indirection and explicit bounds-check branches. Compared with per-object systems, it retains per-pointer precision at the cost of wider pointers and metadata propagation. Compared with hardware fat pointers or capability systems, it requires no new hardware extension but accepts higher overheads and weaker architectural integration. The paper’s broader significance lies in showing that a widened pointer representation, combined with existing SIMD instructions and canonical-address faulting, can provide full spatial bounds checking in software with reported overheads materially below some earlier software-only approaches (Mok et al., 2023).