Why CHERI
Why existing defences are not enough
Testing, fuzzing, code review, sanitizers and exploit mitigations remain essential, but they cannot guarantee that every memory error is found or rendered harmless across a long-lived code base.
Why it matters
CHERI adds another layer: explicit authority checked at the point of use and available for fine-grained containment.
In brief
Testing, fuzzing, code review, sanitizers and exploit mitigations remain essential, but they cannot guarantee that every memory error is found or rendered harmless across a long-lived code base. Many controls detect problems before release or make exploitation less reliable rather than constraining every access in hardware.
Key considerations
1. Testing samples
Tests exercise selected states and inputs; deployed software will encounter combinations the team did not anticipate.
2. Mitigations raise cost
Address randomisation, control-flow and similar defences can frustrate exploitation without enforcing object bounds for every pointer.
3. Patching reacts
Updates remain necessary but arrive after a defect is found and may not reach every deployed system quickly.
Evidence and caveats
Existing defences are not failures and must not be removed. Defence in depth depends on them working with safer languages, CHERI and secure operations.
Use evidence from a named system or source and keep claims proportionate. CHERI is one layer in a broader secure-design strategy.