Zephyr
CHERI-enabled Zephyr brings capability protection to a widely used embedded operating-system ecosystem while platform and feature coverage continue to expand.
Embedded teams often have an established Zephyr codebase, driver model, build system, and board ecosystem. Moving to CHERI should not require them to discard that investment if Zephyr is a hard product requirement.
The CHERI Zephyr work adapts the real-time operating system (RTOS) to use CHERI memory protection and support CHERI-enabled processors.
Why the operating system needs changes
Zephyr normally targets resource-constrained systems and supports several protection configurations. CHERI introduces protected capability state that must be handled across:
- thread creation and context switching
- stacks and memory domains
- system calls and user-mode transitions
- interrupts and exceptions
- object and buffer interfaces
- compiler and linker configuration
- drivers and device memory
- debugging and fault reporting
If any path treats a capability as ordinary integer data, it may lose tags, bounds, or permissions.
Current project structure
CHERI Zephyr development takes place in a CHERI Alliance repository and is coordinated through the CHERI Zephyr Working Group. The repository carries the active source and contribution history, while the working group brings together operating-system, toolchain, hardware, and product contributors.
Support is an active port rather than a feature present in every mainline Zephyr release and board. Check the repository for the current base version, architecture targets, board configurations, samples, test results, and release tags.
What to verify before use
Confirm:
- the CHERI architecture and processor implementation
- supported board or simulator
- compiler and software development kit (SDK) revision
- kernel configuration and privilege mode
- whether application pointers use capabilities broadly
- which memory domains and system calls are capability-aware
- driver and peripheral coverage
- thread, interrupt, and fault tests
- mainline contribution and maintenance status
A successful sample on one board does not establish support for the complete Zephyr hardware catalogue.
Zephyr and CHERIoT are different choices
Both address embedded systems, but they begin from different software models.
- Primary goal: CHERI Zephyr brings CHERI support to the Zephyr ecosystem. CHERIoT is a hardware-software design built around CHERI compartments.
- Existing ecosystem: CHERI Zephyr uses Zephyr application programming interfaces (APIs), drivers, Kconfig, west, and board support. CHERIoT uses its own SDK, compartment model, xmake build system, and supported boards.
- Compartment model: Support depends on the current CHERI Zephyr port and its integration. Compartments are central to the CHERIoT RTOS design.
- Temporal safety: Check the mechanism in the selected CHERI Zephyr build. CHERIoT includes platform mechanisms designed for this purpose.
- Likely fit: CHERI Zephyr suits teams that need compatibility with Zephyr. CHERIoT suits teams that can adopt its hardware-software model.
This is not a maturity ranking. The right choice follows the product’s APIs, devices, safety requirements, compartment design, and supplier path.
A sensible evaluation
- Build the repository’s documented sample on its reference simulator or board.
- Confirm capability state in a debugger or fault report.
- Port one small driver or application component.
- Test stack bounds, object access, threads, and interrupts.
- Deliberately attempt one denied access in a development build.
- Measure memory use, latency, and image size.
- Compare the required security property with CHERIoT or another RTOS route.
Contributing and sources
- Source: CHERI-Alliance/CHERI-zephyr
- Working Group: CHERI Zephyr
- Zephyr documentation: Zephyr Project
Use the CHERI repository’s issue tracker for target-specific bugs and include the exact board, configuration, compiler, commit, and capability-fault output.