Choose a Platform
Choose a CHERI environment by workload, operating system, hardware access, software maturity, and the security property you want to test.
A useful platform choice starts with the development goal. A team porting a Unix service needs a different environment from one building microcontroller firmware. Identify the workload and the result you want to observe before comparing processor names.
Quick comparison
- Learn pure-capability C or C++ in a full operating system: Start with CheriBSD on CHERI-RISC-V in QEMU. It runs locally without CHERI hardware and includes CheriBSD, CHERI LLVM/Clang, and QEMU.
- Port a Unix application or library: Use CheriBSD on CHERI-RISC-V in QEMU, or use Morello when that architecture matters. Morello hardware requires a board or remote lab.
- Explore Linux enablement: Use CHERI Linux on a supported RISC-V target or emulator. The available kernel, Buildroot, user space, and hardware depend on the software development kit (SDK).
- Build compartmentalised embedded firmware: Start with CHERIoT in simulation. Move to Sonata or another supported device when the work needs physical hardware.
- Evaluate an application-class Arm prototype: Use Morello with CheriBSD, CHERI LLVM/Clang, and matching firmware. Some work can use emulation; hardware measurements need a board or remote access.
- Develop or compare processors: Use a CHERI-RISC-V FPGA platform, a Sail formal model, QEMU, or an implementation-specific SDK according to the question being tested.
- Evaluate a product path: Use a supplier SDK and evaluation platform. Access usually involves supplier hardware, an FPGA image, or a licensable processor design.
These routes are starting points. Confirm current target support in the linked project documentation before committing to a product plan.
Start with the security question
Different experiments need different capabilities:
- To observe object bounds in ordinary C code, use a pure-capability environment.
- To compare conventional and capability-aware interfaces, use an environment that supports hybrid builds.
- To test least privilege between small components, choose a platform with a documented compartment model.
- To investigate use-after-free protection, confirm which temporal-safety mechanism the platform and allocator provide.
- To make performance claims, use representative hardware and publish the exact architecture, compiler, application binary interface (ABI), and workload.
A simulator is suitable for functional behaviour and early porting. It is rarely suitable for final timing, power, or microarchitectural conclusions.
Application-class development
CheriBSD on CHERI-RISC-V is a strong general starting point for developers who want a complete Unix-like system without specialist hardware. The cheribuild tool can build the compiler, operating system, disk image, and CHERI-enabled QEMU target.
Morello with CheriBSD provides a mature application-class CHERI stack on Arm’s prototype hardware. It is useful for established Morello projects, hardware measurements, and software that specifically targets the Morello ABI. Morello is an evaluation platform, so new product plans should also consider current commercial CHERI-RISC-V options.
CHERI Linux is appropriate when the Linux kernel and user-space ecosystem are central to the evaluation. Check the CHERI Linux roadmap and repository for current branches, supported processors, and user-space scope.
Embedded development
CHERIoT is designed for small, connected systems. It combines a CHERI-enabled 32-bit RISC-V architecture with a compartmentalised real-time operating system (RTOS) and a defined software model. The official development container includes the compiler, build tools, auditing tools, and simulators.
Use simulation for the first build. Move to Sonata or another supported board when the experiment needs peripherals, physical timing, or hardware integration.
CHERI-enabled Zephyr and other real-time operating-system work may be the better fit when an existing RTOS ecosystem is a hard requirement. Confirm the current port’s architecture and feature coverage before comparing it with CHERIoT.
Five practical selection checks
- Workload: Can the platform run the operating system, libraries, language, and peripherals you need?
- Protection mode: Does the target support pure-capability code, compartments, and any required temporal-safety mechanism?
- Access: Can every developer reproduce the environment through simulation, a board, or a remote lab?
- Evidence: Are the compiler, architecture version, test suite, and implementation status documented well enough for your claim?
- Lifecycle: Is the platform a learning environment, a prototype, an open-source integration target, or a supported commercial product?
Recommended first route
If you have no fixed platform requirement:
- Choose CheriBSD in QEMU for application-class C and C++.
- Choose CHERIoT in its simulator for embedded firmware and compartments.
Your first success criterion should be small: boot the environment, compile a hello-world program, run it, and record the compiler target and software version. Then deliberately trigger one capability violation to confirm that the protection is active in that build.
Continue with Run CHERI in Simulation or compare the detailed Platform Comparison.