The last year has been brutal for businesses globally. Taking examples from my
home country, the UK, the cost is over £1B and still rising, as well as the loss
of at least one life due to cybercrime.
These aren’t isolated incidents – they’re symptoms of a systemic vulnerability
in how we build computer systems.
According to the Verizon 2025 Data Breach Investigations Report, credential
abuse and exploitation of vulnerabilities continue to dominate as attack
vectors, accounting for 22% and 20% of breaches respectively. The exploitation
of vulnerabilities saw a 34% surge year-over-year, creating what Verizon
describes as a “concerning threat landscape”.
We’re yet to learn the root causes and attack chains involved in each of the
examples above, but many involved ransomware, which frequently uses software
exploits as a post-initial-access vector to gain control of target systems and
spread across a network.
Here’s the kicker: approximately 70% of all software vulnerabilities stem
from a single root cause – memory safety issues. This isn’t a new problem.
Google, Microsoft, Apple, Mozilla and the Linux Foundation have all reported
similar figures for their software over the last two decades. The uncomfortable
truth is that current CPUs are fundamentally incapable of preventing these
vulnerabilities, and traditional software patches have proven woefully
inadequate.
Rewriting all the world’s software into memory safe languages, such as C#, Java
and Rust, is unviable. While new projects may be adopting Rust over C/C++, and
some critical components are being rewritten into safe languages, the scale and
depth of the C and C++ ecosystems makes it practically impossible to rewrite all
the world’s unsafe software. The risk of introducing other (non-memory-safety)
issues during a software rewrite also poses a substantial barrier. Given
sufficient software compatibility, it is actually easier to swap the hardware!
Two architectural approaches have emerged to tackle this trillion-dollar problem
at the hardware level:
-
CHERI: Capability Hardware Enhanced RISC Instructions – pioneered at
University of Cambridge (UK), and -
OMA: Object Memory Architecture – pioneered at University of Bristol (UK)
and now being commercialised by Doubtless
Computing.
Both aim to make memory-unsafe systems safe-by-design but they take different
paths to get there. Understanding these differences matters because the choice
between them will shape the security and performance characteristics of
computing for decades to come.
The Memory Safety Crisis
Before diving into solutions, it’s worth understanding what we’re solving. When
software runs, it constantly allocates and deallocates memory – think of it like
booking rooms in a hotel. Memory safety vulnerabilities arise when this process
goes wrong. If you stay in the same hotel twice, you shouldn’t be able to access
your old room even if you remember the number (use-after-free/
use-after-reallocate). Similarly, you shouldn’t be able to enter a neighbouring
room (buffer overflow), or use a room without booking one in the first place
(invalid pointer dereference). Software has these same problems with memory
allocations (room bookings).
These bugs become catastrophic vulnerabilities when attackers exploit them to
read sensitive data they shouldn’t access, manipulate critical system variables,
or inject malicious code. The underlying architecture of today’s processors –
paging-based virtual memory – lacks the granularity needed to enforce security
within a single application or process.
Memory safety breaks down into three categories:
-
Referential safety ensures pointers genuinely reference allocated memory
and can’t be forged. Think of it as ensuring software has a valid booking for
a room, ensuring accesses to memory are authorized, and that bookings can’t be
faked. -
Spatial safety prevents accessing memory outside allocated bounds – no
going into neighbouring rooms. -
Temporal safety addresses what happens over time, ensuring memory can’t be
accessed after it’s been freed and reallocated. In our hotel analogy, a second
stay at the hotel shouldn’t allow you to access your previous room, even if
you remember the room number.
Traditional architectures like x86, Arm, and RISC-V rely on coarse-grained
page-level protection (typically 4KB or larger pages), which is far too blunt an
instrument for modern security needs.
CHERI: Capabilities Meet Legacy Systems
CHERI, developed over more than a decade by the University of Cambridge and SRI
International, extends conventional instruction set architectures with
hardware-enforced capabilities. A CHERI capability is a form of fat pointer –
it contains not just a memory address but also bounds information,
permissions, and validity metadata. Every memory access gets checked against
these constraints in hardware, catching violations before they can be exploited.
The architecture provides strong referential and spatial safety guarantees. When
you have a CHERI capability, you provably have legitimate access to a specific
bounded region of memory, and the hardware won’t let you stray outside those
bounds. CHERI achieves this while maintaining compatibility with existing paged
memory architectures, which is both its greatest strength and a source of
limitations.
Here’s where it gets interesting: CHERI’s capabilities are large. On a 64-bit
system, a CHERI pointer requires 129 bits (including the hidden tag bit) –
essentially double the data width of the base architecture. This decision to encode
all protection metadata within the pointer itself has profound implications.
Every data structure that stores pointers effectively doubles in memory
consumption for those fields. Capabilities in memory (stack/heap) must be aligned to natural 128-bit boundaries. Cache lines, which are precious and limited, now
hold fewer actual pointers. Memory bandwidth requirements increase because
for each pointer you’re moving twice as much data around.
CHERI provides hardware-enforced referential and spatial safety but leaves
temporal safety to software. You can achieve temporal memory safety with
CHERI, but it requires modifying your memory allocator and implementing pointer
revocation mechanisms – essentially software to scan memory to find and
invalidate stale pointers. This software-based approach to temporal safety
remains part of the trusted computing base and requires careful verification.
It’s also closely related to software garbage collection.
Research has explored various temporal safety mechanisms for CHERI, but they all
involve non-trivial software complexity and performance overhead. In theory,
hardware acceleration may be possible but is likely to always require software
involvement. This is because a CHERI capability covers a range of memory, which
may include more than one object. Software allocation and object type
information is required to differentiate objects and thus revoke capabilities
appropriately.
The software ecosystem for CHERI has made impressive progress. Most code
recompiles with minimal changes, though the capability width difference can
require significant rewrites for certain applications. Additionally, it causes a
division in the ISA where load/stores of capabilities must be handled separately
from ordinary data. This leads to some complexity in the compiler to detect edge
cases where the compiler does not know for certain whether a register or memory
slot contains a capability or not. C/C++ code which abuses pointers by treating
them as integers, which is uncommon but frequent enough to cause a headache,
requires some effort to address.
Arm’s Morello project, which implemented CHERI on a modified Neoverse N1 core,
revealed performance challenges that have pushed commercial CHERI efforts toward
smaller embedded processors for the time being. Notably, Arm declined to join
the CHERI Alliance, instead indicating they will take a step back from new work
on Morello and wait to see if CHERI gains the long-sought commercial traction.
OMA: Rethinking Memory From the Ground Up
Doubtless Computing’s Object Memory Architecture takes a fundamentally different
approach. Rather than extending paged memory, OMA implements object-based memory
management directly in hardware. Every allocation becomes a first-class hardware
object with its own identity, bounds, and metadata maintained by the processor
itself.
This architectural choice enables several key advantages. OMA pointers are
leaner – 65 bits on a 64-bit architecture, including the hidden tag bit.
Rather than carrying all metadata with every pointer, OMA stores object
information centrally in hardware-managed directories. This reduces memory
bandwidth requirements and means that multiple pointers to the same object don’t
duplicate metadata. The hardware maintains a complete understanding of object
relationships and lifecycles, enabling optimizations that software-only
approaches can’t match.
A critical differentiator is temporal safety. OMA implements garbage
collection in hardware, scanning for and reclaiming unreachable objects in
real-time as part of the processor’s normal operation. This isn’t the same as
software garbage collection – it’s parallel, highly optimized, and doesn’t block
program execution. By managing object lifecycles in hardware, OMA provides
hardware-guaranteed temporal safety alongside referential and spatial
protections, completing the trinity of memory safety properties.
It would be tempting to say that memory safety is solved by using a managed
language like Java, JavaScript, Swift or Python. Unfortunately, this doesn’t
hold up in practice. Managed language runtimes, as well as many supporting
libraries, are written in C/C++ and suffer memory safety issues just as much as
any other C/C++ code. The operating systems and hypervisors are also exposed to
these languages, offering yet another attack surface. This leaves managed
language apps vulnerable. Memory safe languages, including both Rust and managed
languages, are a distinct improvement over traditional C and C++, but only
hardware can provide the safety guarantees we need in today’s systems.
For managed languages like Java, JavaScript, Python, C# and Go, the OMA
architecture delivers dramatic performance improvements. Doubtless Computing’s
analysis of CPython 3.12 reveals that 32-44% of instructions are spent on memory
management operations – allocation, deallocation, reference counting, and
garbage collection. Moving these operations into parallel hardware execution,
along with microarchitectural optimisations derived from hardware’s new
understanding of the structure of data in memory, yields 2-5x speedups for managed
language applications. Even C/C++ applications see 1.2-2x improvements as the
hardware optimizes memory management functions and eliminates per-object metadata from
cache.
The architecture maintains full source code compatibility for managed languages –
all changes are confined to the runtime. For C/C++, the story is much the same
as with CHERI: recompilation with modified standard libraries and a modified
compiler, such as LLVM or GCC. Maintaining the pointer width the same as the
data width, and the same alignment requirements, avoids the ISA-level split for
handling pointers, which simplifies the compiler and improves compatibility with
legacy C/C++ code. This compatibility approach differs from CHERI’s and aligns
with OMA’s target market: server-class and application processors, where managed
languages dominate.
Fundamental Trade-offs: Where the Architectures Diverge
The philosophical differences between CHERI and OMA create distinct trade-off
profiles. CHERI carries all metadata with pointers, enabling incremental
adoption where different parts of a program can use capabilities independently.
OMA’s centralized metadata requires the hardware to maintain a consistent view
of all objects but enables more aggressive optimization. CHERI works within the
existing paged memory model, simplifying system software migration. OMA
introduces a new memory model that requires deeper changes but delivers
performance gains that paged architectures can’t match.
These differences manifest in pointer width – CHERI’s 129-bit capabilities
versus OMA’s 65-bit pointers. While both exceed the base address width, the
doubling effect in CHERI has more severe implications for data structure
layouts, cache efficiency, and memory bandwidth. Research on CHERI
implementations has shown there is a long road ahead to achieve performance
parity for managed languages. In the meantime, OMA offers a shorter path with
substantial speedups rather than equal performance.
Temporal safety represents perhaps the most significant divergence in security. CHERI’s
software-based pointer revocation requires explicit memory scanning and
manipulation, adding complexity to the trusted computing base and verification
burden. OMA’s hardware garbage collection happens transparently and
continuously, providing stronger guarantees with less software complexity. This
matters enormously for total cost of ownership – every line of security-critical
software that doesn’t need to be written, verified, and maintained is a win.
The instruction set philosophies differ too. CHERI historically opts for ISA changes
beyond pure memory safety to achieve its security goals, which can complicate
adoption. OMA has historically prioritized backward compatibility, though this
is adaptable based on market requirements. The consensus in the industry is that
software compatibility presents the primary barrier to new processor designs,
which favours architectures that minimize disruption.
Industrial Relevance and Market Fit
CHERI and OMA target fundamentally different computing environments, which is
why calling them competitors misses the point. They’re complementary solutions
to a shared problem, each optimized for distinct use cases.
CHERI finds its natural home in embedded systems and microcontrollers. These
environments predominantly use C, C++, or Rust with restricted or no dynamic memory
allocation. The code bases are smaller and more amenable to the verification
required to ensure CHERI capabilities are used correctly. The memory overhead
from wider pointers, while still present, matters less in resource-constrained
designs that carefully manage every allocation. Four companies – SCI
Semiconductor, Codasip, lowRISC, and Secqai – are actively commercializing CHERI
for embedded applications. SCI’s ICENI family of CHERIoT microcontrollers, built
on Microsoft’s open-source CHERIoT-Ibex core, targets the IoT and operational
technology markets. Codasip offers CHERI-enabled RISC-V IP cores for custom
processor designs. lowRISC’s Sonata platform provides an open-source FPGA-based
development environment for CHERIoT research and prototyping.
Arm’s experience with CHERI tells an important story about scaling limitations.
The Morello project, which implemented CHERI on a modified Neoverse N1
server-class core, yielded results that Arm appears to have found
unsatisfactory. There has been no apparent follow-up on the substantial initial
investment made into the Arm Morello designs. This assessment seems to reflect
the performance challenges that CHERI faces in larger systems.
OMA’s sweet spot sits at the opposite end of the spectrum. Application-class and
server-class processors running managed languages benefit enormously from
hardware-accelerated memory management. Python, Java, JavaScript, C#, and Go all
share similar memory models that align naturally with OMA’s object-based
approach. These environments already use garbage collection extensively, so
moving that functionality into hardware removes overhead, rather than adding it
as it would in embedded systems. The performance gains – up to 5x for managed
languages – become transformational for data centre workloads where every
percentage point of efficiency translates to millions in operating costs.
The market dynamics favour different adoption paths. CHERI benefits from strong
government backing, particularly from the now-ended UK’s Digital Security by Design
programme and recognition from the US White House and NSA. This institutional
support hopes to accelerate adoption in defence and critical infrastructure
applications. CHERI’s open-source foundation through the CHERI Alliance creates
a broad ecosystem but limits opportunities for proprietary differentiation.
OMA’s proprietary nature and performance advantages position it for commercial
data centre deployment. The technology directly addresses the performance
problems that hindered CHERI at scale. While OMA lacks CHERI’s first-mover
advantage and government momentum, it offers compelling value for cloud
providers and enterprises running managed language workloads. The economic
argument is straightforward: if you can eliminate 70% of vulnerabilities while
quintupling performance for your Python services, the return on investment is
measured in weeks from deployment, rather than years.
OMA’s proprietary technology makes it attractive for investment as it can be
patented. However, CHERI’s openness makes it possible for independent security
teams to verify the safety of the architecture. Open implementations of CHERI
processors also enables those designs to be independently verified. Doubtless
Computing will need to make its ISA public, which is inevitable anyway for a new
CPU as customers will require it. Doubtless will also need to offer a public
platform for independent researchers to build confidence in the security claims.
The CHERI Ecosystem: Who’s Building What
The CHERI Alliance, formally launched in 2024, coordinates standardization and
adoption efforts across industry and academia. Founding members include the
FreeBSD Foundation, Capabilities Limited, SCI Semiconductor, Codasip, lowRISC,
and the University of Cambridge. Google’s participation as a founding member
signals serious industry interest, though notably Arm is not a member.
SCI Semiconductor, based in Cambridge, leads commercialization of Microsoft’s open-source CHERIoT Ibex
implementation for embedded systems. Their ICENI family of processors targets microcontroller applications in automotive,
industrial control, defence, and aerospace. The company has secured strategic
distribution through EPS Global, which specializes in automotive tier-one
suppliers and contract manufacturers. SCI’s early access program, in collaboration with lowRISC, allows select
partners to begin development on lowRISC’s FPGA-based Sonata platform with
guaranteed migration paths to production silicon.
Codasip, a RISC-V processor IP vendor, offers the X730 – a CHERI-enabled 64-bit
application-class core based on their A730 design. Their “Custom Compute”
methodology allows customers to license CHERI-enhanced cores or customize them
further using Codasip Studio. The company has donated a CHERI SDK built on
open-source tools to the CHERI Alliance, making it freely available for anyone
implementing CHERI on RISC-V. Codasip is also developing Linux kernel support
for RISC-V CHERI, which will be crucial for broader adoption.
lowRISC, a not-for-profit organization spun out of Cambridge University,
maintains the Sonata evaluation platform and leads the UK-government-funded
Sunburst Project. Sonata provides a complete FPGA-based development environment
for CHERIoT, enabling software development and hardware experimentation before
silicon is available. The Sunburst Project’s recent expansion to include SCI
Semiconductor aims to validate CHERIoT designs through commercial tapeout on
GlobalFoundries’ 22nm process, with all project deliverables remaining
open-source.
zeroRISC is a startup and partner in the OpenTitan
project administered by lowRISC. Their goal is to commercialise the OpenTitan
silicon IP through their Integrity Management Platform.
Microsoft’s role deserves special mention. Microsoft Research developed
CHERIoT-Ibex, an open-source RISC-V core optimized for embedded systems. They’ve
made this core freely available and co-maintain the CHERIoT Platform repository
with SCI Semiconductor. David Weston, Microsoft’s VP of Enterprise and OS
Security, has publicly endorsed SCI’s commercialization efforts, stating that
CHERI represents a “promising technology that can be used to enhance computer
security.” This corporate backing from a major software vendor adds credibility
to the embedded CHERI ecosystem.
The UK government’s support through the now-ended Digital Security by Design programme and
UKRI funding has been instrumental in advancing CHERI. The programme provided
~£190 million in research funding over five years and continues to support
development through initiatives like Sunburst. This institutional backing,
combined with endorsements from the US White House and NSA, positions CHERI
advantageously for government and defence procurements.
Conclusions
CHERI and OMA represent two responses to the memory safety crisis, each with
distinct strengths that make them suited to different computing environments.
The notion that one must “win” while the other “loses” misunderstands the
landscape – the computing world is large enough, and varied enough, that
multiple approaches can and should coexist. Cybersecurity principles also demand
diversity of solutions.
CHERI’s compatibility with existing paged memory architectures and incremental
deployment model make it an excellent fit for embedded systems where code bases
are manageable, languages are predominantly C/C++/Rust, and the verification
burden is acceptable. The active CHERI ecosystem, backed by government support
and open-source collaboration, has created momentum that shouldn’t be
underestimated. For IoT devices, industrial control systems, and safety-critical
embedded applications, CHERI offers a practical path to hardware-enforced memory
safety that companies can adopt today.
OMA’s object-based architecture and integrated hardware garbage collection (IHGC)
deliver transformational performance for managed language workloads. By tackling
temporal safety in hardware alongside referential and spatial protections, OMA
provides more complete memory safety with less software complexity. The
performance gains – up to 5x for Python, Java, JavaScript, C#, and Go – directly
address the scalability problems that have limited CHERI in larger systems. For
data centres, cloud infrastructure, and application servers where managed
languages dominate, OMA presents compelling advantages.
Both architectures eliminate memory safety vulnerabilities. The formal
guarantees that CHERI can provide are a subset of what OMA delivers, since
OMA includes hardware-enforced temporal safety. However, CHERI’s earlier start
and ecosystem momentum matter significantly in technology adoption. The question
isn’t which architecture is “better” in absolute terms but rather which is more
appropriate for specific use cases and deployment contexts.
Looking ahead, memory safety will increasingly become a non-negotiable
requirement. The UK National Cyber Security Centre, US White House, and NSA have
all called for fundamental changes in how we build secure systems. The attacks
on Marks & Spencer, Co-op, Jaguar Land Rover, the NHS, Transport for London, and
many others, demonstrate that our current approach isn’t working. Software-only
solutions like Rust, while valuable, face adoption barriers that make them
insufficient on their own. Hardware-based memory safety, whether through CHERI,
OMA, or future approaches we haven’t yet invented, represents the most practical
path to eliminating this class of vulnerability at scale.
The semiconductor industry moves slowly, with design cycles measured in years
and deployment timelines measured in decades. Today’s architectural decisions
will shape computing security through 2040 and beyond. The good news is that we
now have proven approaches to memory safety that work in real hardware. CHERI
has demonstrated its viability in embedded systems. OMA has shown it can deliver
both security and performance for managed languages with a hardware prototype on
AWS Cloud FPGAs supporting CPython 3.12 and Jupyter Notebooks. The challenge now
isn’t technical feasibility – it’s economic deployment and ecosystem
coordination.
For embedded designers, CHERI offers immediate benefits with manageable
overhead. For cloud and data centre operators, OMA promises to eliminate
vulnerabilities while dramatically improving performance. The fundamental
insight is that both approaches work by making the right choices for their
target markets. We don’t need to pick one winner. We need both, deployed where
each makes the most sense, steadily displacing the insecure architectures that
enabled the attacks we’ve seen this year. The trillion-dollar memory safety
problem is solvable – and the will to deploy the solutions we’ve built is
growing as organisations can no longer afford the risk of being vulnerable.
