Skip to content

Arm Morello

Arm Morello

memory-safety hardware

The first industrial-scale CHERI silicon: a Neoverse N1 retrofitted with 128-bit capabilities, the closeout of UK DSbD.

§1 Provenance

§2 Mechanism

Morello adapts an Armv8.2-A Neoverse N1 SoC by adding the CHERI capability model as a new architectural state. The N1 cores are extended with:

  • Capability registers C0-C30, CSP, PCC, DDC (the “default data capability” used to relocate legacy non-cap loads/stores) — 129 bits wide including tag.
  • New instructions: LDR/STR variants that take a capability base, SCBNDS to shrink bounds, SEAL/UNSEAL, BLR via sealed sentry, etc.
  • A tag-storage controller in the memory subsystem keeping one tag bit per 128-bit DRAM granule, stored in a reserved physical region.

The capability layout is the canonical CHERI Concentrate 128-bit format: ~18 bits permissions, ~16 bits otype, ~20 bits compressed bounds (mantissa+exponent), 64 bits cursor, plus the side-band tag. Morello drove two ISAv9 design choices: (i) non-monotonic modification clears the tag instead of trapping, (ii) DDC/PCC do not relocate legacy memory accesses by default.

The SoC is dual-cluster, 4-core Cortex-A-class with the Morello extensions, packaged on a development board with 16 GB DDR4 and full peripherals.

§3 Threat model + guarantees

Same as CHERI ISA in §1 file:

  • Spatial safety on every pointer, including pointers crossing DMA via the SMMU when properly configured.
  • Pointer integrity via the side-band tag; no software-readable encoding.
  • Compartmentalisation via sealed sentries.
  • Temporal safety only with a revocation runtime (Cornucopia / Cornucopia Reloaded), not with bare Morello.
  • Spectre v1/v2/v4 mitigations are inherited from Neoverse N1; no new side-channel protection from CHERI.
  • The April 2025 NATO ICMCIS paper identifies five new failure modes specific to Morello deployment if mis-configured: state leaks, memory leaks, UAF, unsafe defaults, and toolchain instability.

Morello does not protect against: confidentiality leaks (tag is integrity-only), uninitialised reads, type confusion at the language level, or in-compartment logic bugs.

§4 Production status (May 2026)

Morello was always a research prototype, not a product. As of May 2026:

  • The Morello board (silicon date 2021, distribution since early 2022) shipped in the low hundreds of units to academic and industrial partners — Google, Microsoft, Cambridge, Edinburgh, multiple UK SMEs.
  • The UK DSbD programme (Innovate UK, EPSRC, Arm, total ~£200M public+private 2019-2024) closed out in October 2025 with the Final Impact Evaluation Report. Headline numbers: 405 new jobs created (vs. 100 target), £29.6M projected GVA, 80% of TAP survey respondents would consider the Morello board for future products, and a programme-level claim that “DSbD technology can mitigate 70% of known memory-safety vulnerabilities.”
  • No follow-on commercial Morello silicon from Arm. The capability-ISA torch for Arm itself has effectively passed to (a) CHERIoT for embedded and (b) the upstream RISC-V CHERI standardisation work. Arm publicly remains a CHERI Alliance member but has not, as of May 2026, announced a roadmap silicon product carrying Morello-style capabilities.
  • The “Morello Industrial Demonstrator” projects (a TAP cohort funded by DSbD) ran 2023-2024 and produced about a dozen ports of real codebases (PostgreSQL, Nginx, parts of FreeBSD userspace, an automotive AUTOSAR stack). Reported porting effort is single-digit percent of LoC changed for clean modern C, growing for code with heavy pointer-int aliasing or DMA.
  • IEEE CS awarded the 2024 Best Paper to the CHERI / Morello team’s S&P Magazine paper (announced Aug 2025).

§5 Software emulation cost

Approximating Morello’s guarantees in software (e.g., a port of CheriABI to QEMU TCG, or SoftBound+CETS-style instrumentation) costs roughly:

  • 2-3x slowdown on pointer-heavy SPEC workloads with full bounds+temporal checks (CETS+SoftBound).
  • ~25% memory overhead for shadow-pointer metadata (vs. <1% on Morello which uses sideband tag bits).
  • ~50-100% slowdown for QEMU-instrumented capability semantics (this is largely interpreter overhead, not the safety per se).

The Morello papers report typical 0-5% perf overhead on hardware for spatial safety alone, climbing to 10-30% with temporal-safety via Cornucopia. That gap is the canonical “what the hardware buys you” number for any software runtime trying to approximate the same guarantee.

§6 Mochi adaptation note

Morello’s main relevance to vm3 is as the upper bound on what is possible rather than as a target. Three takeaways:

  1. Morello’s 128-bit fat pointer with sideband tag is more expressive than the 8-byte vm3 Cell, but vm3 trades expressiveness for fixed-shape arena/slab indexing: bounds are implicit (slot size), provenance is the generation. We are essentially Morello-with-omitted-fields, optimised for a single-process managed runtime.
  2. Morello’s “clears tag on non-monotonic modify” behaviour maps directly to vm3’s “stale generation on slot reuse” — we just bump rather than clear. The user-visible effect (next dereference traps) is the same.
  3. Where vm3 falls short of Morello: per-pointer permissions (no PE/PW/PR/Pseal in our Cell) and compartmentalisation (sealed sentries). If MEP-41 wants either, it should look at carving permission bits out of the arena-tag nibble or out of the unused high bits of the slab index, not at widening the Cell.

We should not aim to match Morello’s compartment story in software; that’s MEP-15 effects’ job. We should match its spatial-and-provenance story exactly, which we already do, and document the missing “permissions on the handle” as a deliberate omission justified by the type system.

Reference MEP-40 (handle layout: 4-bit arena tag, 12-bit gen, 32-bit slab index) and MEP-15 (effects as the compartment substitute).

§7 Open questions for MEP-41 design

  1. Should mochi build ever target a Morello/X730 backend that maps Cells onto real 128-bit capabilities and elides the software generation check? What’s the conformance story?
  2. The Morello programme’s “70% of CVEs” headline number was a programme-level claim across multiple TAP cohorts, not a per-vuln measurement; can we set a more concrete vm3 acceptance target (e.g., “trap 100% of OSV-DB use-after-free PoCs in a Mochi standard-library port of CPython’s _ctypes”)?
  3. Morello’s lessons on DMA and SMMU integration: do we need an “untrusted memory” arena class in vm3 for, e.g., mmap’d files or shared memory with native peers?
  4. Should the Morello porting blockers (state leaks, unsafe defaults, toolchain instability) inform MEP-41’s defaults? In particular, should vm3 default to deny on any operation that would clear or skip a generation check?
  5. Given that Arm has not committed to a Morello follow-on, do we treat Morello as historical and orient MEP-41 toward CHERI-RISC-V (X730/Sonata) instead?