TL;DR OpenTitan® is extending the Ibex® processor to support CHERI, leveraging the CHERIoT RISC-V instruction set architecture, to significantly improve memory safety and enable scalable compartmentalization within its silicon root of trust. By replacing standard pointers with hardware-managed “capabilities,” CHERI delivers deterministic protection with minimal overhead. This integration allows OpenTitan to maintain its established secure boot flow while offering an optional, powerful layer of runtime enforcement for “Silicon Owner” firmware, where the volume of security-critical, often third-party code creates the highest risk.
Introduction
A root of trust is the component to which every other security claim of a platform ultimately reduces. Secure boot, measured attestation, sealed storage, key management — all of them are only as strong as the small chip (or the small part of a chip) that anchors them. That concentration of trust is the whole point of a root of trust (RoT), but it cuts both ways: a single exploitable bug in RoT firmware does not compromise just one application, it undermines the security story of the entire product built on top of it.
Meanwhile, memory safety remains the dominant source of serious vulnerabilities. Microsoft and the Chromium project have both reported that roughly 70% of their serious security vulnerabilities are memory-safety bugs — out-of-bounds accesses, use-after-free, and their relatives — and the problem is now prominent enough that CISA and the NSA issued joint guidance in 2025 urging the industry away from memory-unsafe languages. Where that shift happens, it demonstrably works: after Google moved new Android development to memory-safe languages, the share of memory-safety bugs among Android vulnerabilities fell from 76% in 2019 to 24% in 2024. RoT firmware, however, is overwhelmingly written in C, and there is no reason to believe it is exempt.
CHERIoT changes the economics of this problem for small embedded systems. It not only provides memory safety guarantees but also allows scalable fine-grained compartmentalisation with safe sharing. In this article we recap briefly what CHERI and the CHERIoT implementation provides, and then make the case for why OpenTitan — the open-source silicon root of trust, shipping both as a discrete chip and as an integrated block in a larger System on Chip (SoC) — is one of the places where deploying it pays off most.
CHERIoT in a nutshell
CHERIoT is a RISC-V instruction set architecture that adapts CHERI capabilities to small 32-bit embedded cores. Instead of raw integer addresses, pointers become capabilities: hardware-managed values that carry bounds, permissions, and an unforgeable validity tag alongside the address. Every load, store, and jump is checked against the capability that authorizes it, in hardware, on every access.
Figure 1: 64-bit CHERIoT capability that consists of a 32-bit address, a 6-bits permission field (read, write, execute, …), a 3-bit object type, as well as a 22-bit bound. There is one reserved bit and the validity tag bit is an extra bit, separate from the 64-bit capability.
This approach yields three properties that C and C++ cannot give you on their own:
- Spatial safety. A pointer to a 64-byte buffer cannot be used to access byte 65. Out-of-bounds accesses trap deterministically instead of silently corrupting an adjacent state or leaking sensitive data.
- Temporal safety. CHERIoT provides deterministic use-after-free protection: a load filter and an optional background revocation engine ensure that capabilities to freed memory can no longer be dereferenced.
- Pointer integrity. Capability tags are maintained exclusively by the hardware. Overwriting a pointer with attacker-controlled data clears the tag; forging a pointer out of an integer is impossible.
On top of these, CHERIoT builds a lightweight compartment model. A compartment is a unit of code and data with explicitly exported entry points; calls between compartments are hardware-mediated, and one compartment can hand other capabilities to selected objects — and nothing else — for the duration of a call. Crucially, the number of compartments is bounded only by available memory, not by a fixed number of hardware regions in a memory protection unit, and the isolation properties of a firmware image can be statically audited at build time.
The reference implementation, CHERIoT-Ibex, extends the Ibex processor — the same lowRISC® RISC-V core that OpenTitan uses today. That lineage is not a coincidence, and we will come back to this later in the article. CHERIoT-Ibex was created by Microsoft, and lowRISC was involved in its verification.
In summary; the general case for CHERI has been made elsewhere, and made well: Microsoft’s security response team concluded that CHERI would have deterministically mitigated at least two thirds of the memory-safety vulnerabilities reported to it in 2019, and the UK government’s Digital Security by Design programme has invested heavily in maturing the technology into deployable hardware. The more interesting question is what CHERI specifically buys a root of trust.
A root of trust runs security-critical C — lots of it
The software that runs on a root of trust is overwhelmingly written in C and C++, and the bulk of it is Silicon Owner firmware: the code that a device owner runs on the chip from the first owner boot stage (called BL0 in OpenTitan) onward. This is where the volume and variety lives — owner-specific libraries, data parsers, key-management services, and increasingly whole protocol stacks such as SPDM. Owner firmware is large, evolves throughout a product’s life, pulls in third-party components, and handles most of the externally influenced input that reaches the chip.
It is also within reach of the most valuable assets on the chip. The same C code that parses attacker-influenceable certificates and protocol messages executes next to secret keys, device configuration, and confidential data. A missed bounds check, an off-by-one in a length calculation, a stale pointer — in today’s hardware these are silent memory corruption, and memory corruption in a root of trust is as bad as it gets: the attacker can exploit those memory corruptions enabling them to potentially compromising secure boot on the device or extracting user secrets. Hand-hardening every memory access, as is done for a few kilobytes of boot code, does not scale to a body of firmware this large and this fast-moving. CHERI turns the entire bug class into deterministic traps, enforced by hardware on every access.
The standard rejoinder is “rewrite it in Rust,” and OpenTitan does embrace Rust where it fits. But language safety and hardware safety are complements, not substitutes. The existing C code base, including third-party libraries, is not going away; Rust programs still link unsafe code and C via FFI; and — most importantly — a memory-safe language does little to isolate separately compiled components from one another at run time. That last problem is where the CHERIoT implementation excels.
Isolating less-trusted code: where ePMP runs out of road
A root of trust running only first-party firmware is the simple case. Increasingly, it is not the typical case — for discrete chips and integrated enclaves alike. A discrete OpenTitan in a laptop, server, or vehicle may run manufacturer firmware: product-specific services and applications written by the device maker, executing alongside base firmware written by a different organization entirely. When OpenTitan is integrated into a larger SoC like a secure enclave, the number of parties involved in writing the firmware is even larger: owner firmware beside silicon-creator code, loadable services, protocol stacks handling external input. In both form factors, the trust boundary is no longer just “the RoT versus the outside world” — it runs through the RoT itself.
What must that boundary protect? Above all, memory-mapped assets: the key manager, one-time programmable (OTP) memory and memory controllers, and crypto accelerator interfaces are all memory-mapped input/output (MMIO) regions, and only the most trusted software should be able to touch them. Less-trusted code needs enough access to do its job and not one register more.
OpenTitan’s tool for this today is RISC-V’s enhanced Physical Memory Protection (ePMP): a set of address-range registers with priority-ordered matching. It works — OpenTitan’s boot stages use it carefully to enforce W^X and to lock down assets before handing off control — but anyone who has worked with it knows it is an awkward foundation for fine-grained isolation:
- The region budget is tiny and global. OpenTitan provisions 16 ePMP regions, and they are a chip-wide resource that ROM, ROM_EXT, and owner firmware must share across handoffs, with entries consumed by code regions, stack guards, and MMIO windows. Every new isolation boundary competes for the same 16 slots.
- Semantics are positional and easy to get wrong. Lower-numbered entries silently take priority over higher-numbered ones, so the index at which each stage places an entry is load-bearing. OpenTitan’s ROM maintains a shadow copy of the entire ePMP state in working memory just to be able to check that the CSRs contain what the code believes they contain.
- Granularity is ranges, not objects. ePMP can wall off “the MMIO segment” or, at best, one peripheral’s address window per precious entry. It cannot express “this compartment may use the AES block but only through these registers,” let alone “this driver may access this one direct memory access descriptor.”
This is not a criticism of OpenTitan’s ePMP code, which is state of the art for what the mechanism offers. It is a criticism of the mechanism: a handful of priority-ordered range registers, reconfigured in careful choreography at every boot stage, is simply not the right abstraction for a system whose trust boundaries are multiplying.
But CHERIoT’s compartment model is the right abstraction. Each device’s MMIO range is reachable only through a capability, and the build system hands that capability to exactly the compartments that declare a need for it — per device, or as fine-grained as a single register block. Compartments scale with memory, not with a 16-entry budget. There is no priority-ordering trap and no cross-stage CSR choreography: isolation is a property of which capabilities a compartment holds, established at link time and enforced on every access. And because compartment linkage is explicit, the question “which code can touch the key manager?” has a machine-checkable answer, produced by an auditing tool rather than by a careful reading of boot-stage assembly.
“Surely we can’t afford it” — the area question
Capability hardware has a reputation for being expensive, and for a root of trust — often one of the most area-constrained blocks in the entire SoC — that reputation would be disqualifying if it were accurate. It is not, and we now have numbers for OpenTitan’s own core to show it.
We synthesized three Ibex configurations and measured: a baseline Ibex at 57 kGE; Ibex with the 16-region ePMP that OpenTitan ships today at 81 kGE (+42%); and Ibex extended with CHERI at 90 kGE (+57% over baseline).
For OpenTitan there is a twist to this arithmetic. Because the boot stages keep running under ePMP and the switch to CHERI happens once, at run time (more on this below), we are building a dual-ISA configuration of the core that implements both protection mechanisms side by side — so we pay the area for both rather than trading one for the other. We have representative numbers for the core as OpenTitan actually instantiates it, with 16 ePMP regions and dual-core lockstep for fault detection:
- On the core, CHERI adds about 47 kGE. OpenTitan’s current Ibex configuration comes to roughly 197 kGE1; the dual-ISA configuration, with CHERI added alongside ePMP, to roughly 244 kGE — an increase of about 24%.
- Against the whole root of trust, that disappears into the noise. A complete OpenTitan-class RoT — on-chip non-volatile memory, volatile memory, OTP memory, crypto accelerators, peripherals — measures on the order of a few million gate equivalents. An extra ~47 kGE of core logic, plus a fraction of a percent for memory tag bits, comes to a low single-digit percentage of the RoT, and far less again when integrated into a larger SoC.
For that price, entire vulnerability classes become deterministic traps. There are very few line items in a silicon budget with a better security return.
From argument to silicon
This is not a hypothetical proposal. lowRISC and the OpenTitan partners have started the work of bringing CHERI to OpenTitan, building on Microsoft’s CHERIoT-Ibex core and the experience gained from the Sonata platform, and we expect to complete the effort by early 2027.
We strictly limit the scope of this integration so that OpenTitan’s proven secure-boot flow remains untouched. OpenTitan’s boot stages — the mask ROM and ROM_EXT — remain exactly as they are today, with their existing hardening and ePMP-based lockdown, so the proven secure-boot flow is untouched. What we add is an option at the trust boundary where it matters: before executing the first Silicon Owner code (typically BL0), the chip can switch the core into CHERI mode — a one-time transition per boot — so that everything from the owner’s first instruction onward runs under capability enforcement and can be structured as compartments. Owners who opt out see no change at all. We will share technical details — the hardware integration, the handoff mechanics, and the compartmentalisation of owner firmware — as the work progresses.
Conclusion
OpenTitan’s value proposition is trustworthiness, established through transparency: open silicon, open firmware, open verification. CHERI extends that trustworthiness from design-time assurance to run-time enforcement. The three arguments stand independently — the large, fast-moving body of security-critical C that owners run on a root of trust deserves deterministic memory safety; multiplying trust boundaries inside the RoT — discrete or integrated — need an isolation model that scales beyond 16 range registers; and the silicon cost is a rounding error at system level — but together they make OpenTitan not just a plausible candidate for CHERI, but one of the platforms where it belongs first.
Get Involved
The OpenTitan project is stewarded by lowRISC C.I.C. a not-for-profit engineering company that creates and maintains commercial-grade open source silicon designs through its collaborative Silicon Commons® approach.
If you build on a root of trust — whether you are an SoC architect integrating a secure enclave, a manufacturer shipping your own services on a discrete security chip, or a firmware team asked to run code you did not write next to keys you must protect — we would like to hear from you at: get-involved@opentitan.org.
- The difference between the baseline Ibex (57 kGE) and the Ibex used in OpenTitan today (197 kGE) comes from the ePMP registers and the additional physical security hardening that is enabled with the SecureIbex parameter.