Why CHERI
Approaches to memory safety
Memory safety needs layers: safer languages, testing, hardening, hardware enforcement and compartmentalisation address different failure modes and lifecycle constraints.
Why it matters
The right combination depends on new versus existing code, unsafe dependencies, product lifetime, performance, assurance and the ability to replace components.
In brief
Memory safety needs layers. Memory-safe languages prevent broad classes of mistakes; testing and analysis find defects; conventional mitigations make exploitation harder; CHERI adds hardware-enforced pointer protection and supports stronger compartments.
Key considerations
1. Prevent
Use memory-safe languages and safer interfaces for new code wherever practical.
2. Detect
Apply review, testing, fuzzing, sanitizers and capability-aware compiler diagnostics.
3. Enforce and contain
Use CHERI bounds, permissions, provenance and compartments to restrict invalid access and component authority.
Evidence and caveats
No single layer covers every memory error or every security problem. State which code and threats each control covers and how the layers interact.
Use evidence from a named system or source and keep claims proportionate. CHERI is one layer in a broader secure-design strategy.