Adoption Costs & Migration

Migration does not have to begin with a rewrite or an entire product line. A controlled path can start in simulation, move through a representative component, and expand only when the evidence supports it.

Where costs arise

Migration work usually falls into five areas:

• Platform: selecting processor intellectual property, hardware, firmware, an operating system, a simulator, and a deployment route.
• Software: recompiling code, correcting pointer assumptions, changing interfaces, reviewing assembly, and designing compartments.
• Tools: integrating builds, continuous testing, debuggers, analysers, package management, and release automation.
• People: learning capability concepts, porting patterns, debugging methods, and assurance practices.
• Product: testing performance and memory use, qualifying suppliers, certification, documentation, and support.

The mix depends on the execution model. A hybrid system can retain conventional pointers in part of the application while introducing capabilities at selected boundaries. A pure-capability system uses capabilities for all pointers and provides broader enforcement, but usually exposes more assumptions during a port.

A staged migration

1. Inventory. Map native code, third-party dependencies, assembly, hardware interfaces, allocators, and trust boundaries.
2. Select a platform. Choose an environment that matches the intended product closely enough to answer the main questions.
3. Create a clean baseline. Build and test the unmodified component before interpreting CHERI-specific failures.
4. Port a representative slice. Include realistic pointer use and an interface to less-trusted input.
5. Measure. Compare correctness, performance, memory footprint, image size, developer effort, and diagnostic quality.
6. Add containment. Where supported, place a risky component in a compartment with only the authority it needs.
7. Set a gate. Decide whether to expand, change approach, or stop.

Common sources of porting work

Code that converts pointers to integers, reconstructs pointers from unrelated values, assumes pointers are a particular size, stores metadata in pointer bits, or uses custom memory management deserves early attention. The compiler can expose many of these assumptions. Tests should then confirm behaviour at allocation, lifetime, and component boundaries.

Third-party code needs an ownership decision: update to an available CHERI port, contribute changes to the main project, maintain a local patch, isolate the component, or replace it. Include that maintenance choice in the cost model.

Reduce transition risk

Keep conventional and CHERI builds from the same source where practical. Add both to continuous integration. Document intentional compatibility code and test every security boundary. Prefer changes that can be contributed to the main project over a growing private fork.

The porting guidance describes common technical patterns, while Choose a Platform helps match evaluation goals to available environments.