Case Studies
CHERI has been explored in large operating systems, embedded platforms, existing applications, and commercial processor products, showing where capability protection can fit.
CHERI began as an architectural research project, but its value has been explored far beyond small demonstrations. Processor prototypes, operating systems, embedded platforms, application ports, and commercial intellectual property show how the same capability principles apply at different scales. A capability is a processor-protected reference that records where software may access memory and what it may do there.
These examples do not prove that CHERI fits every product. They show that capability protection can coexist with substantial software stacks, resource-constrained systems, and existing C and C++ code.
Morello: a complete experimental stack
The Morello programme brought CHERI concepts into an experimental Arm architecture, processor, development board, toolchain, and software environment. It supported both hybrid execution, where capabilities and conventional pointers coexist, and pure-capability execution, where pointers are capabilities throughout the protected software.
Morello gave research and industry teams a realistic platform for porting operating systems and applications, examining compatibility, and measuring performance. It showed that CHERI could be applied to a sophisticated 64-bit application processor rather than only to a specialised research core.
Morello remains an experimental platform. Its importance lies in the full-stack evidence and experience it created, not in representing a production Arm architecture.
CheriBSD: established software at operating-system scale
CheriBSD adapts FreeBSD to CHERI. It includes capability-aware kernel and user-space software, pure-capability execution, and work on compartmentalisation.
The port shows how a large C codebase can move incrementally. Compiler diagnostics and runtime faults expose assumptions about pointers, memory layout, and interfaces that conventional systems permit. The operating-system environment also provides a base for running and studying substantial applications.
This makes CheriBSD relevant to products that depend on mature native software and need evidence about the cost and effect of protecting it. Results still depend on the platform, configuration, workload, and status of each port.
CHERIoT: protection for small embedded devices
The CHERIoT platform combines a 32-bit CHERI-RISC-V architecture, processor core, toolchain, and real-time operating system. It is designed around small compartments that do not trust one another and can communicate through controlled interfaces.
CHERIoT shows why CHERI can fit microcontrollers that lack the memory-management hardware used for process isolation on larger systems. It also combines capability protection with mechanisms intended to support temporal memory safety in constrained devices.
The cheriot-ibex core was certified under version 1.0 of the CHERI Enabled programme on 26 March 2026. Its published certification record describes the implementation, verification evidence, excluded configuration, and integration assumptions.
Commercial processor intellectual property
Codasip’s X730-MP4-Lux is a commercially licensable 64-bit application-processor intellectual-property product implementing CHERI-RISC-V. Its CHERI Enabled record describes supported execution modes, verification work, temporal-safety support, debug behaviour, and implementation assumptions.
This demonstrates a route from CHERI research into processor technology available for commercial system-on-chip designs. The certification applies to the named processor product and version, not automatically to a chip, operating system, or complete product built around it.
What the examples show together
Across these case studies, CHERI appears in two recurring situations:
- existing low-level software has continuing value but needs stronger memory protection;
- components share hardware while requiring much narrower authority over one another.
The examples also show that CHERI is an ecosystem change rather than one processor feature. Toolchains, operating systems, runtimes, libraries, debugging, and assurance all influence whether the architectural protection becomes useful in a product.