CHERI Linux
CHERI Linux adapts the kernel and user-space foundations so Linux workloads can use capability memory protection across supported processors.
Many products and cloud systems require Linux. Even when a CHERI processor and compiler exist, a Linux stack must still preserve capability state through boot, scheduling, virtual memory, system calls, signals, executable loading, debugging, and user-space libraries.
CHERI Linux is the ecosystem effort to provide that support across CHERI architectures and implementations.
Scope of the work
Linux enablement includes changes to:
- architecture boot and exception handling
- capability register context switching
- virtual memory and page-table integration
- user access helpers and pointer validation
- executable loading and relocations
- application binary interfaces (ABIs) for system calls
- signals, tracing, core dumps, and debugging
- device and direct-memory-access (DMA) interactions
- C library, dynamic linker, and Buildroot or distribution user space
- compiler, emulator, and processor software development kits (SDKs)
Kernel support alone does not create a usable pure-capability Linux product. The kernel, compiler, C library, loader, packages, and target hardware must form one compatible stack.
Current organisation
The CHERI Alliance Linux Working Group coordinates a cross-architecture roadmap, priorities, public repositories, meetings, and contribution routes. The aim is to avoid isolated vendor ports and move towards a coherent Linux approach that can serve multiple CHERI processors.
Public work includes CHERI-RISC-V kernel branches and integration of lessons from earlier Morello Linux development. The repositories are active and the base kernel evolves as work is rebased and prepared for broader review.
CHERI support is not yet a standard feature of a mainline Linux release. Use the Alliance roadmap and repository documentation for current branches, supported processors, and user-space components.
Typical development environments
A CHERI Linux SDK may include:
- a CHERI-aware cross compiler
- Linux kernel source and configuration
- QEMU or a supplier simulator
- Buildroot or another root-filesystem build
- C library and dynamic loader changes
- example applications
- FPGA or board deployment tools
Commercial processor suppliers may provide a tested combination for their own implementation. Match the SDK to the processor architecture and version.
When to choose CHERI Linux
- The product already depends on Linux kernel interfaces or drivers.
- Existing user space is a central part of the evaluation.
- The team wants to contribute support to the main Linux project.
- A commercial CHERI-RISC-V platform supplies a Linux SDK.
- Cloud, data-centre, networking, or application workloads need Linux-specific measurement.
For learning generic pure-capability C and C++ without a Linux requirement, CheriBSD in QEMU may offer a quicker starting path.
Evaluate the complete stack
Ask:
- Which kernel version and branch is used?
- Which CHERI architecture and processor are supported?
- Is the kernel itself capability-aware, the user space pure capability, or both?
- Which C library and dynamic loader are included?
- Which system calls, drivers, signals, tracing, and debugging paths are tested?
- How are conventional and capability-aware binaries handled?
- Which tests run in QEMU, FPGA, and silicon?
- What is the mainline contribution and long-term maintenance plan?
A small booting root filesystem is not equivalent to a general-purpose distribution. Record the packages and interfaces that are present.
Contributing
- Roadmap: CHERI Roadmap for Linux
- Project documentation: cheri-linux.org
- Alliance repositories: github.com/CHERI-Alliance
- Working Group: CHERI Linux
When reporting an issue, include the kernel commit, compiler and target system headers and libraries (sysroot), target processor or emulator, ABI, root-filesystem build, configuration, and the complete capability-fault output.