Arm's Memory Tagging Extension attaches a small tag to memory and to pointers and checks that they match on each access, so it catches many bugs with modest changes. CHERI replaces plain addresses with hardware capabilities that carry bounds and permissions, and needs deeper software changes.
How MTE works
According to Android's documentation, MTE assigns a tag to a memory location, which can then be associated with pointers that reference it. At run time the CPU checks that the pointer tag and the memory tag match on loads and stores. Tags apply to 16 byte aligned chunks called granules. On a mismatch the process is stopped with a segmentation fault signal.
It detects use after free and buffer overflows and underflows. In the default overflow tuning, adjacent allocations get distinct tags, so linear overflows are caught deterministically. In the other tuning, tags are randomized and the documented chance of detecting both spatial and temporal bugs is a uniform 93% or so.
What MTE can miss
The documentation is clear about limits. MTE cannot detect an overflow within the same tag granule and can miss small overflows. It is disabled by default and is a process wide property. The ONCD report adds that MTE is effective at detecting memory bugs but is not a comprehensive way to prevent all exploits.
How CHERI works
CHERI, from SRI International and the University of Cambridge, adds architecture features that give fine grained memory protection and compartmentalization. Programs use capabilities, hardware supported descriptions of permissions, instead of plain integer addresses. It is a hybrid design that works alongside conventional MMU based systems and C and C++ code. Prototypes include CHERI-RISC-V on FPGAs and Arm Morello, an experimental CHERI enabled processor and board.
Side by side
- Mechanism. MTE checks a tag match on every access. CHERI uses capabilities that carry bounds and permissions.
- Source changes. MTE mostly touches the allocator and runtime. CHERI needs a recompile and often some code adaptation.
- Detection or prevention. MTE is described as detection, with a stated probability for some bug types. CHERI aims at bounds enforcement.
- Maturity in the sources. MTE is documented in Android's pages. CHERI appears as research platforms and prototypes.
The last point reflects what the fetched pages say, not a market survey.
Questions to ask before you plan around either
For MTE, ask whether your target devices support it, whether your allocator integrates it, and whether the processes you care about can enable it. Remember that it is disabled by default and set per process, so someone must own the switch.
For CHERI, ask whether your toolchain and operating system exist for your platform at the maturity you need. The Cambridge page lists prototype software stacks, including an adapted Clang and LLVM, a FreeBSD variant, FreeRTOS and WebKit, which is encouraging for research and evaluation.
In both cases, treat hardware as one layer. The ONCD report calls hardware and formal methods complementary to memory safe languages, not substitutes for them.
What to do today
If your fleet has MTE capable hardware, SYNC mode is documented as suited to testing and critical processes, and ASYNC mode to production on well tested code. For CHERI, follow the project, since the sources describe prototypes rather than broad products.
Quick check
Does MTE make a C program memory safe?
No. It detects many bugs at run time, but misses some, and a detected bug still ends the process.
Sources
- Android, Arm Memory Tagging Extension
- University of Cambridge, CHERI project
- Back to the Building Blocks, ONCD, February 2024
Last reviewed: 19 October 2026.
