Hardware-enforced security
Software will make mistakes. Limit what happens next.
CHERI gives processors a stronger way to control memory access, helping systems block invalid operations and contain compromised components.
Understand the problem01 / The problem
The problem reaches everyday life.
Software sometimes accesses memory it should not. One mistake can expose personal information, disrupt a service or let an attacker change part of a device. Memory safety is a human, commercial and resilience issue.
- At homeConnected devices
Privacy, availability and long product lifetimes depend on trustworthy software boundaries.
- On the moveVehicles and transport
Safety-critical functions coexist with connectivity, third-party code and demanding updates.
- In careMedical equipment
Reliability, controlled access and clear fault detection remain valuable for years.
- In publicCritical services
A compromised component should not automatically gain authority over a whole system.
02 / Where risk appears
Complex software sits inside familiar products.
Phones, routers, connected appliances, vehicles, medical equipment and public infrastructure all depend on software. Memory errors do not always become attacks, but exploitable errors can expose data, corrupt another component or interrupt a service.
03 / Defence in depth
Good engineering matters. It needs layers.
Testing, analysis, memory-safe languages and conventional mitigations all do important work. CHERI adds hardware-enforced restrictions. It is an additional layer, not a replacement.
- Layer 01Reduce exploitability
Use conventional mitigations and secure configuration.
- Layer 02Find mistakes
Use review, testing, fuzzing, analysis and sanitizers.
- Layer 03Prevent mistakes
Use memory-safe languages and carefully designed interfaces.
- Layer 04Enforce authority
Use CHERI bounds, permissions, validity and compartments.
04 / A long-standing idea
Authority, with limits.
Capability systems are not a sudden invention. CHERI builds on an idea developed and tested over decades, adapted for modern processors and software.
- 1960s–70sCapability foundations
Early systems establish authority carried by protected references.
- 2010CHERI begins
Cambridge and SRI combine capability ideas with modern processor architecture.
- 2014–20Hardware and software
Architecture, FPGA processors, CheriBSD and formal methods advance together.
- 2022 onwardLarge-scale evaluation
Morello and a growing RISC-V and embedded ecosystem expand practical evaluation.
05 / What CHERI changes
Every pointer carries authority the hardware can check.
Capabilities carry information used to enforce where software may access memory and what it may do there.
- Step 01Attempt
Software attempts to access a memory address.
- Step 02Validate
The processor checks protected validity, bounds and permissions.
- Step 03Decide
A valid request continues; an invalid request faults at the point of use.
- Step 04Contain
A compartment boundary can limit the authority of a compromised component.
06 / Validation
From foundations to whole-system evidence.
CHERI grew through sustained hardware, software and formal-methods development. Research programmes and development platforms enabled progressively broader evaluation.
07 / Ecosystem
From architecture to working systems.
CHERI spans processors, boards, operating systems, compilers, languages and tools. Every entry needs a clear maturity label and a dated source.
- Development platformArm Morello
Large-scale CHERI evaluation across a rich operating-system stack.
- Open FPGA platformSonata
Embedded research, teaching and prototyping.
- Embedded architectureCHERIoT
Fine-grained compartments for embedded systems.
- Software stackCheriBSD and LLVM
Operating-system and compiler support for application evaluation.
08 / Outcomes, qualified
Change the path from mistake to impact.
Hardware-enforced restrictions can reduce opportunities to exploit memory errors, improve fault detection and support stronger isolation.
- 01Software mistake
The underlying programming error may still occur.
- 02Restricted authority
The component has only the access it needs.
- 03Invalid access blocked
The processor checks the request at the point of use.
- 04Compromise contained
A compartment boundary may limit wider impact.
09 / The economic decision
Security is a lifecycle decision.
Compare investigation, patching, downtime and long-term support with the real costs of hardware change, porting, training, testing and assurance.
- BaselineCurrent exposure
Support, incident, recall, downtime and assurance costs.
- AdoptionTransition cost
Hardware, porting, tools, skills, testing and certification.
- ComparisonExplicit ranges
Low, central and high assumptions with evidence quality shown.
10 / Complementary controls
CHERI and Rust are stronger together.
Memory-safe languages prevent many mistakes in new code. CHERI adds hardware-enforced protection across mixed-language systems and established code.
- Language layerRust and memory-safe languages
Prevent broad classes of errors and express ownership and lifetimes.
- Hardware layerCHERI capabilities
Enforce bounds and permissions across new, mixed and established code.
- System outcomeLayered memory safety
Combine prevention, enforcement and stronger containment.
11 / Why an Alliance
Adoption is a team sport.
An architecture is not enough. Practical adoption needs platforms, maintained tools, shared evidence, skills, assurance and interoperable specifications.
- Hardware and softwareInteroperable systems
Coordinate architecture, platforms, tools and maintained software.
- Research and educationEvidence and skills
Make learning, evidence and implementation guidance visible.
- Industry and governmentAdoption and assurance
Connect practical needs to standards, policy and procurement.
12 / Choose your next step
Where do you want to go next?
Choose a route by intent. Each route states what the reader should expect to understand or accomplish.