Rust

Rust prevents many memory errors in safe code, but a real Rust system still depends on a target application binary interface (ABI), compiler back end, standard library, allocator, operating system, and native interfaces. Bringing Rust to CHERI therefore requires more than adding a processor name to a target list.

Support exists across several CHERI projects, but it is not one uniform, stable target family. Confirm the exact platform before selecting Rust for a product.

Why combine Rust and CHERI

Safe Rust uses ownership, borrowing, lifetimes, and type checking to reject many invalid programs before they run. CHERI enforces capability authority when memory is accessed and can divide components into compartments.

Together they can provide:

• language-level prevention for safe Rust
• hardware bounds and permissions beneath raw pointers
• stronger containment for C libraries called through a foreign-function interface (FFI)
• least-privilege boundaries between Rust components
• protection for operating-system and runtime code outside safe Rust

CHERI does not replace Rust’s language guarantees, and Rust does not replace CHERI’s authority model.

What a Rust port needs

A useful target requires agreement across:

• LLVM or another code-generation back end
• pointer representation and address spaces
• target ABI and calling convention
• rustc target specification
• core and standard libraries
• allocator and panic behaviour
• unwinding or abort model
• operating-system system calls
• C interface and generated-binding (bindgen) assumptions
• debugger and build tools

Pointer width deserves special care. A capability representation may be wider than the virtual address range. Code must not infer addressable memory or index width from size_of::<*const T>().

Current platform routes

Morello and CheriBSD

Rust ports have targeted Morello with freestanding and CheriBSD environments. They demonstrate Rust code, standard-library work, and native interfaces on an application-class CHERI platform. These toolchains may use project forks and pinned compiler revisions rather than a standard Rust release channel.

CHERI-RISC-V

Rust target work also covers CHERI-RISC-V and pure-capability environments. Target names, operating-system support, and standard-library completeness differ between projects. Verify active repositories and tests before depending on a specific triple.

CHERIoT

Rust support for CHERIoT is under active development within its embedded hardware-software ecosystem. The CHERIoT C and C++ software development kit (SDK) remains the most established route for current examples and platform interfaces. Check CHERIoT release notes and working-group resources for the current Rust toolchain, supported language subset, real-time operating-system (RTOS) integration, and board coverage.

Unsafe Rust on CHERI

Unsafe Rust permits raw pointer dereference, foreign calls, mutable statics, and other operations whose invariants the compiler cannot prove. On a pure-capability CHERI target, raw pointers can still be capability-based and subject to hardware bounds and permissions.

This is valuable defence in depth, but it does not make every unsafe block correct. A raw capability may have broad bounds, and an in-bounds write can still violate Rust’s aliasing or initialisation rules.

Audit unsafe code for both sets of invariants:

• Rust safety requirements
• CHERI bounds, permissions, provenance, and lifetime behaviour

Foreign-function interfaces

Rust frequently calls C libraries. Both sides must use a compatible ABI and agree on pointer layout, ownership, and lifetime.

Review generated bindings for:

• pointer-sized integer assumptions
• packed structures
• callbacks and function pointers
• variadic functions
• opaque handles
• buffers represented as pointer plus length
• C allocation released by Rust or the reverse

A compartment can provide a stronger boundary than an in-process FFI call when the native library is large or exposed to untrusted input.

Evaluating maturity

Before adoption, confirm:

1. Which rustc revision and target are supported?
2. Is core, alloc, or the full standard library available?
3. Which operating system, RTOS, or bare-metal runtime is tested?
4. Do Cargo, build scripts, bindgen, and procedural macros work in the development flow?
5. How are panics, unwinding, threads, atomics, and TLS handled?
6. Which continuous-integration tests run on a simulator, FPGA, or silicon?
7. Is the toolchain maintained and suitable for the product lifecycle?

Follow the Rust + CHERI Working Group and platform repositories for current support. For the conceptual relationship, read CHERI and Rust.