CHERI-SIMT: Implementing Capability Memory Protection in GPUs

Matthew Naylor, Alexandre Joannou, A. Theodore Markettos, Paul Metzger, Simon W. Moore and Timothy M. Jones

Memory-safety bugs cause most security vulnerabilities, and governments now push memory-safe technologies like CHERI — which replaces raw pointers with tamper-proof capabilities carrying bounds and permissions, so out-of-bounds and use-after-free accesses are caught while C and C++ keep working — but CHERI was built for CPUs, and naively adding it to a GPU is ruinously expensive, more than doubling register storage and adding 44 percent chip area because each fat capability is replicated across every thread in a warp; this paper (University of Cambridge — Matthew Naylor, Simon Moore, Timothy Jones, and colleagues) presents CHERI-SIMT, which exploits the fact that threads in a warp share nearly identical capability metadata to store and process it once instead of per lane — cutting register-storage overhead from 103 percent to 7 percent and runtime overhead to 1.6 percent.

The argument in one glance

Problem

The best hardware memory-safety technology was built for CPUs, and GPUs cannot afford it

Memory-safety bugs — out-of-bounds accesses (spatial violations) and use-after-free errors (temporal violations) — cause around 70 percent of security vulnerabilities in major software, so governments now urge the industry toward memory-safe technologies. One of the recommended ones is CHERI (Capability Hardware Enhanced RISC Instructions), which builds strong memory safety into the instruction-set architecture: it replaces raw integer pointers with capabilities, tamper-proof pointers that carry bounds and permissions and are protected by a tag bit distinguishing a real capability from ordinary data. Because a capability cannot be forged or fabricated from arbitrary data, out-of-bounds and use-after-free accesses are caught in hardware, and existing C and C++ code keeps working, just memory-safely. The problem is that CHERI was developed for CPUs, and GPUs also run unsafe C/C++ dialects like CUDA and OpenCL, with the same memory-safety risks. Bringing CHERI to a GPU is punishingly expensive: a capability is far larger than a plain pointer (each 32-bit register grows by 33 bits of metadata plus a tag), and on a GPU that fat metadata and the logic to manipulate it must be replicated across every thread in a warp and every vector lane. A naive port more than doubles register-file storage and adds large area and time costs.
What people did

Port CHERI to the GPU the way it was done for CPUs

The straightforward approach is to take CHERI as designed for CPUs and replicate it across the GPU. Every thread gets full capability registers — each holding the pointer plus its bounds, permissions, and tag — and every execution unit (vector lane) gets its own copy of the logic to check and manipulate capabilities, just as a CPU core has one set of capability machinery.
Why it fell short

Replicating fat capabilities across every lane blows up storage and area

A GPU is not one core but many lanes running in lockstep, so replicating CHERI's per-pointer machinery multiplies its cost by the number of lanes. Each capability roughly doubles the size of a register (a 32-bit value becomes 32 bits of address plus 33 bits of metadata and a tag), and because that is stored for every thread in every warp, a naive implementation inflates register-file storage by 103 percent — more than doubling it. Replicating the capability-manipulation logic in every execution unit adds about 44 percent to the logic area. There is also an execution-time cost from all the extra capability handling. These overheads are far too high for a GPU, where register-file storage and area are precious and multiplied across thousands of lanes. Simply doing what worked on CPUs does not translate. What is needed is a way to provide the same capability memory safety on a GPU without paying to replicate the bulky capability metadata and logic across every lane.
This paper's idea

Exploit warp regularity to store and process capabilities once, not per lane

CHERI-SIMT makes CHERI affordable on GPUs by exploiting the regularity of Single Instruction, Multiple Thread (SIMT) execution, where a warp of threads runs the same instruction together. The key observation is that the capability metadata is highly redundant across a warp. Threads in a warp typically point into the same array or buffer, so they share the same bounds and permissions and differ only in the address (offset) — a pattern the CUDA programming guide even encourages, recommending uniform or affine (unit-stride) addresses. GPU warps show three kinds of regularity the design leverages: control-flow regularity (threads follow the same path, so an instruction, including a capability instruction, is fetched and decoded once per warp and run by all lanes), and value regularity in the capability metadata (the bounds, permissions, and tag are identical or affine across lanes). Exploiting this, CHERI-SIMT stores the shared capability metadata once for the whole warp instead of replicating it per lane, and processes capabilities in a shared-function unit rather than duplicating the logic in every lane — without hurting run-time performance, because the metadata is regular. With basic compiler support to limit how many registers hold capabilities, the cost drops further. The authors implement a large subset of version 9 of the 32-bit CHERI standard in SIMTight, an open-source synthesisable SIMT GPU with a CUDA-like C++ environment, and evaluate on FPGA: register-file storage overhead falls from 103 percent to 7 percent (below 3.5 percent of total on-chip storage), logic-area overhead from 44 percent to about one extra multiplier per lane, and execution-time overhead to 1.6 percent.

Why this problem is worth solving

Memory safety has become a top-level security priority, and GPUs are a large, unprotected surface running the same unsafe languages that plague CPUs.

The majority of serious security vulnerabilities — around 70 percent in major software projects — come from memory-safety bugs: reading or writing outside an object’s bounds (spatial safety), or using memory after it has been freed (temporal safety). These arise because C and C++ let programs manipulate raw pointers with no checks. Rewriting the world’s C/C++ in a safe language is impractical, so a major line of defense is to make the hardware enforce safety while keeping the language. CHERI does exactly this. It augments the instruction-set architecture so that a pointer is no longer a bare integer but a capability: the address plus metadata describing the bounds of the region it may access and the permissions it has, all protected by a tag bit that hardware maintains and that cannot be set by ordinary data writes. Every memory access through a capability is checked against its bounds and permissions, so an out-of-bounds or use-after-free access is caught at the point of use rather than silently corrupting memory. Crucially, existing C/C++ can be recompiled to use capabilities with modest changes, so decades of software can become memory-safe without a rewrite. Governments now explicitly recommend such technologies, which is why the industry, including GPU vendors, faces pressure to adopt them — and GPUs, programmed in unsafe dialects like CUDA and OpenCL, are squarely in scope.

The difficulty is that a GPU multiplies CHERI’s per-pointer cost by its enormous width.

On a CPU, CHERI’s cost is largely paid once: the register file holds capabilities that are about twice the size of plain pointers, and the core has one set of logic to check and manipulate them. That overhead is real but tolerable on a single core. A GPU is architecturally different: it executes in a Single Instruction, Multiple Thread style, where a warp of many threads runs the same instruction across many parallel vector lanes, and a streaming multiprocessor has as many execution units as threads in a warp. So anything CHERI adds per pointer or per lane is replicated across the whole width of the machine. A capability roughly doubles register size — a 32-bit address gains 33 bits of compressed bounds and permissions plus a tag — and because every one of the many threads stores its own capabilities, the register-file storage overhead balloons to 103 percent, more than doubling one of the GPU’s most precious and area-hungry resources. The logic to manipulate capabilities, replicated in every lane, adds roughly 44 percent to the logic area. And there is extra execution time from all the capability handling. On a GPU, where register storage and area are multiplied by thousands of lanes, these costs are prohibitive. So the very architecture that makes GPUs fast — massive replicated parallelism — is what makes a naive CHERI port unaffordable, and that is the obstacle CHERI-SIMT must overcome.

What people did before, and where it broke

Leave GPU code memory-unsafe. Accept that CUDA and OpenCL are unsafe C/C++ dialects and rely on testing. Where it broke. Memory-safety bugs remain, and with governments pushing memory-safe technologies, unprotected GPU code is an increasingly untenable security and compliance gap.
Rewrite GPU code in a memory-safe language. Replace C/C++-based GPU programming with something safe. Where it broke. It abandons the enormous existing base of CUDA/OpenCL code and established programming practices, which is impractical at scale.
Port CHERI to the GPU as designed for CPUs. Give every thread full capability registers and every lane its own capability logic. Where it broke. GPUs replicate everything across many lanes, so this inflates register-file storage by 103 percent and logic area by 44 percent — far too expensive.
Shrink capabilities generically. Try to make the metadata smaller without regard to how GPUs execute. Where it broke. Generic compression does not exploit the specific redundancy of a warp, so it cannot remove the per-lane replication that dominates the GPU cost.
The gap. No implementation delivered CHERI’s capability memory safety on a GPU at an affordable cost, by exploiting the fact that capability metadata is largely identical across the threads of a warp.

How CHERI-SIMT works

Turning per-lane capability overhead into per-warp cost

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Enforce memory safety with hardware capabilities. CHERI-SIMT’s foundation is the CHERI model itself: replace raw pointers with capabilities that carry bounds and permissions and are guarded by a tag, so the hardware catches every out-of-bounds or dangling access. Using capability hardware to make C/C++ memory-safe, including the difficult case of temporal safety against use-after-free, is the same foundation the work on load barriers for CHERI heap temporal safety covered elsewhere on this site builds on, hardening the CHERI capability system against dangling pointers. CHERI-SIMT carries that same capability protection to the GPU, where the challenge is doing so without paying for it in every lane.

Exploit the redundancy of a warp to pay once instead of per lane. The heart of CHERI-SIMT is the observation that a warp’s threads are highly regular — same control flow, and near-identical capability metadata — so the bulky per-pointer information can be stored and processed once for the whole warp rather than replicated across every lane. Recognizing and exploiting the value redundancy across the threads of a GPU warp to avoid duplicated work and storage is the same insight the work on exploring value patterns in GPU-accelerated applications covered elsewhere on this site is built on, finding that GPU lanes carry far more identical data than they appear to. CHERI-SIMT turns that redundancy specifically into cheap capability storage and shared capability logic.

Deliver spatial and temporal memory safety without changing how people program. Ultimately CHERI-SIMT is about catching the out-of-bounds and use-after-free bugs that dominate vulnerabilities, while letting developers keep writing C/C++. Providing practical protection against memory-safety violations, especially the temporal use-after-free errors that are hardest to stop, is the same goal the work on practical mitigation of temporal memory-safety violations covered elsewhere on this site pursues, defending real code against these bugs at acceptable cost. CHERI-SIMT extends that protection to the GPU, keeping the CUDA and OpenCL programming model intact while making it memory-safe.

Following a buffer overread through CHERI-SIMT

Catching an out-of-bounds GPU access cheaply

A trace, drawn from the paper, of how CHERI-SIMT stops a bad access while keeping capability cost low.

Step 1 of 5

A GPU kernel makes an out-of-bounds access

A warp of threads runs a kernel where a pointer into an array is used to read one element past its end — a spatial memory-safety violation that, unchecked, would leak a neighbouring variable's value, as in a classic buffer overread.

This is the kind of bug that causes a large share of security vulnerabilities.

Why it works

Warp threads share capability metadata, so it need not be replicated. Threads in a warp usually point into the same buffer → so their bounds, permissions, and tag are identical or affine across lanes → so storing that metadata once per warp, not per lane, removes most of the register cost.
Control-flow regularity lets capability logic be shared. All lanes of a warp run the same instruction together → so a capability instruction is fetched, decoded, and its shared logic executed once → so a shared-function unit replaces per-lane logic without slowing execution.
Only the address really differs across lanes. The part of a capability that varies per thread is just the address → so CHERI-SIMT keeps addresses per lane but shares everything else → so it preserves correctness while collapsing the bulky metadata.
Cheap storage keeps the whole-chip overhead tiny. The register file is fewer than half of total on-chip storage → so cutting its CHERI overhead to 7 percent → so the overall storage overhead falls below 3.5 percent of the chip.
Sharing does not sacrifice the safety guarantee. The bounds and permissions checked are still the real ones for each access → so out-of-bounds and use-after-free accesses are still caught → so CHERI-SIMT gives full capability memory safety at a fraction of the naive cost (1.6 percent execution time).

What it costs (trade-offs and scope)

The savings depend on warps actually being regular. The dramatic reductions come from threads in a warp sharing capability metadata; code where lanes point into many different buffers with unrelated bounds has less redundancy to exploit, so its overhead would be higher (closer to the naive per-lane cost).
It needs compiler support and capability-aware code. Reaching the lowest overheads relies on basic compiler support to limit how many registers hold capabilities, and on recompiling C/C++ to use capabilities; existing binaries do not become safe for free.
It implements a large subset, not all, of CHERI. The prototype covers a large subset of version 9 of the 32-bit CHERI standard (excluding, for example, atomics in the instruction figure); a complete production implementation would need the remaining pieces.
It is evaluated on a research GPU in simulation and on FPGA. The design and numbers come from SIMTight, an open-source synthesisable SIMT core, measured on FPGA; a commercial GPU differs in scale and microarchitecture, so exact overheads there could vary, though the redundancy the approach exploits is fundamental to SIMT.
It adds memory safety, not other protections. CHERI-SIMT targets spatial and temporal memory safety via capabilities; it is not a defense against every GPU security issue (for example, side channels), and it presumes the CHERI capability model and its assumptions.

The evaluation

Adding CHERI memory safety to a GPU

Property	No memory safety	Naive CHERI port	CHERI-SIMT
Catches out-of-bounds and use-after-free
Register-file storage overhead
Logic-area overhead
Execution-time overhead
Keeps the C/C++ programming model

A comparison of ways to handle GPU memory safety. CHERI-SIMT delivers full CHERI capability safety on a SIMT GPU by exploiting warp regularity, cutting register-file storage overhead from 103 percent to 7 percent, logic area to about one extra multiplier per lane, and execution-time overhead to 1.6 percent, evaluated in the SIMTight open-source GPU on FPGA.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (the authors’ PDF of the ASPLOS 2026 paper). The mechanism described is the paper’s: CHERI-SIMT implements CHERI capability memory protection efficiently in a Single Instruction, Multiple Thread (SIMT) GPU by exploiting warp regularity. It observes large redundancy in the capability metadata across threads in a warp (which typically share bounds and permissions, differing only in address — value regularity), together with control-flow regularity, and therefore stores the shared capability metadata once per warp rather than per lane and processes capabilities in a shared-function unit rather than replicating the logic per lane, without impacting run-time performance; basic compiler support to limit the number of registers holding capabilities reduces overhead further. The authors implement a large subset of version 9 of the 32-bit CHERI standard in SIMTight, an open-source synthesisable SIMT core with a CUDA-like C++ environment (NoCL), and evaluate on FPGA. Reported results: register-file storage overhead reduced from 103 percent to 7 percent (and, since the register file is fewer than half of total on-chip storage, overall storage overhead below 3.5 percent), logic-area overhead reduced from 44 percent to a cost comparable to one additional multiplier per vector lane, and execution-time overhead reduced to 1.6 percent. Exact microarchitectural details, the CHERI subset, and full results should be read from the paper.

Background

Why memory safety is becoming a hardware mandate everywhere

It helps to see CHERI-SIMT within a broad, policy-driven push to eliminate memory-safety bugs, which have caused the majority of serious security vulnerabilities for decades. The realization that testing and careful coding will never fully solve the problem in C and C++ has moved the industry toward structural fixes — safe languages like Rust for new code, and hardware-enforced safety like CHERI for the vast existing C/C++ base — and governments are now explicitly recommending these technologies. As that mandate spreads, it cannot stop at the CPU: modern systems run enormous amounts of code on accelerators, and GPUs in particular execute unsafe C/C++ dialects at massive scale, so leaving them unprotected would leave a gaping hole. The challenge is that security mechanisms designed for CPUs rarely transplant cheaply to accelerators, whose architectures make different trade-offs, so each new substrate needs its costs re-engineered rather than merely copied. This is a general pattern: as protections become mandatory, the research work shifts to making them affordable on every kind of hardware. The wider effort to extend strong, hardware-rooted protection to accelerator hardware that previously lacked it is the same terrain the work on shielded enclaves for cloud FPGAs covered elsewhere on this site occupies, carrying security guarantees to a new device class. CHERI-SIMT shows that, by exploiting the structure of GPU execution, capability memory safety can reach the GPU at a cost low enough to be practical, which is what a hardware-safety mandate ultimately requires.

If you remember only three things

1. Memory-safety bugs (out-of-bounds accesses and use-after-free) cause around 70 percent of serious security vulnerabilities, and CHERI makes C/C++ memory-safe in hardware by replacing raw pointers with tamper-proof capabilities that carry bounds and permissions (guarded by a tag bit), catching bad accesses at the point of use. But CHERI was built for CPUs, and GPUs — programmed in unsafe dialects like CUDA and OpenCL — are punishingly expensive to protect this way, because a capability is far larger than a pointer and a naive port replicates that fat metadata and its logic across every thread in a warp and every vector lane, inflating register-file storage by 103 percent and logic area by 44 percent.
2. CHERI-SIMT makes CHERI affordable on GPUs by exploiting warp regularity: threads in a warp usually point into the same buffer, so their capability metadata (bounds, permissions, tag) is identical or affine across lanes, differing only in the address. So instead of replicating the full capability per lane, CHERI-SIMT stores the shared metadata once per warp and processes capabilities in a shared-function unit rather than duplicating the logic per lane — using control-flow and value regularity so this costs no run-time performance — with light compiler support to limit capability-holding registers.
3. Implemented in the open-source SIMTight SIMT GPU (a large subset of 32-bit CHERI version 9) and evaluated on FPGA, CHERI-SIMT cuts register-file storage overhead from 103 percent to 7 percent (below 3.5 percent of total on-chip storage), logic area from 44 percent to about one extra multiplier per lane, and execution-time overhead to 1.6 percent — a viable path to strong, efficient GPU memory safety that keeps the C/C++ programming model. The gains depend on warps being regular, it needs capability-aware recompilation, and it is evaluated on a research GPU.

Check yourself

Check your understanding

1. Why is a naive port of CHERI so expensive on a GPU compared with a CPU?
2. What key observation lets CHERI-SIMT make CHERI affordable on a GPU?
3. How does CHERI-SIMT turn that observation into lower cost without weakening safety?
4. Predict: CHERI-SIMT runs a kernel whose threads in each warp point into many different, unrelated buffers with different bounds. How would its overhead compare to a well-behaved kernel, and why?

Sources

The paper is “CHERI-SIMT: Implementing Capability Memory Protection in GPUs” by Matthew Naylor, Alexandre Joannou, A. Theodore Markettos, Paul Metzger, Simon W. Moore, and Timothy M. Jones (University of Cambridge), published at ASPLOS 2026, DOI 10.1145/3760250.3762234.

This explainer is written from the paper’s full text (the authors’ PDF). Memory-safety bugs cause around 70 percent of security vulnerabilities, and governments increasingly recommend memory-safe technologies such as CHERI (Capability Hardware Enhanced RISC Instructions), which builds strong memory safety into the instruction-set architecture by replacing integer pointers with capabilities (address plus bounds and permissions, protected by a tag), allowing continued but memory-safe use of C/C++. GPUs also run unsafe C/C++ dialects like CUDA and OpenCL, but a naive CHERI implementation is expensive because capabilities are large and must be replicated across every thread in a warp and every vector lane. CHERI-SIMT exploits the regularity of Single Instruction, Multiple Thread execution: it observes large redundancy in capability metadata across a warp (threads sharing bounds and permissions, differing only in address, plus control-flow regularity), and therefore stores the shared metadata once per warp instead of per lane and processes capabilities in a shared-function unit rather than replicating logic per lane, without impacting run-time performance, with basic compiler support reducing overhead further. The authors implement a large subset of version 9 of the 32-bit CHERI standard in SIMTight, an open-source synthesisable SIMT core with a CUDA-like C++ environment, and evaluate on FPGA, reducing register-file storage overhead from 103 percent to 7 percent (overall storage overhead below 3.5 percent since the register file is fewer than half of total on-chip storage), logic-area overhead from 44 percent to a cost comparable to one additional multiplier per vector lane, and execution-time overhead to 1.6 percent. No numbers beyond the paper’s own have been introduced; exact microarchitectural details, the CHERI subset, and full results should be confirmed in the paper.