Looking at the past
Pointers Were Never Meant to Be Just Numbers
(And C Didn’t Kill That Idea… We Did)
Ask a C programmer what a pointer is, and you’ll almost certainly hear:
“It’s just a memory address.”
That statement is true in practice, but historically wrong.
The idea that a pointer is “just a number” is not a law of computing. It is the result of a long chain of economic and engineering decisions that happened to align in the 1970s and 1980s.
Before that, and increasingly again today, a pointer was understood as something richer: a reference with rules, a capability, a guarded object.
And crucially: C did not invent flat memory. It merely adapted itself to it extremely well.
Before C: When Pointers Carried Meaning
Early computer systems had no illusion that memory access was harmless.
Machines such as the Burroughs B5000, the Unisys 1100/2200 series, and later the Lisp Machines all treated pointers as structured entities:
- bounds-checked
- tagged
- validated by hardware
- often unforgeable
A pointer was not an integer you could increment freely. It was closer to a capability, a permission to access a specific object.
This wasn’t academic purity. It was a necessity:
- multi-user systems
- shared memory
- batch scheduling
- safety over speed
These machines enforced correctness by design.
C Did Not “Flatten” Memory… It Adapted to It
It’s tempting to say:
“C introduced flat memory and unsafe pointers.”
That’s not quite true.
C was designed on the PDP-11, a machine that already had:
- a flat address space
- no hardware memory tagging
- no segmentation protection at the language level
C didn’t invent this model… It embraced it.
But here’s the key point that often gets missed:
C was explicitly designed to be portable across architectures with very different memory models.
And that includes machines that did not have flat memory.
C on Non-Flat Architectures: The Forgotten Chapter
C was successfully implemented on:
- segmented machines
- descriptor-based systems
- capability-like architectures
Including Unisys systems, where pointers were not simple integers.
As documented in historical work (and summarized well in begriffs.com – “C Portability”), early C compilers adapted to the host architecture rather than forcing a universal memory model.
On Unisys systems:
- pointers were implemented using descriptors
- arithmetic was constrained
- bounds and access rules were enforced by hardware
- the compiler handled translation
This worked because the C standard never required pointers to be raw addresses.
It required:
- comparability
- dereferenceability
- consistent behavior
Not bit-level identity.
Even Henry Rabinowitz warned, in Portable C, that assuming pointer arithmetic behaved like integer arithmetic was already non-portable, even in the late 1980s.
So what changed?
The Real Shift: Economics, Not Language Design
The shift didn’t come from C.
It came from:
- cheap RAM
- fast CPUs
- simple pipelines
- RISC philosophy
- UNIX portability
Flat memory was faster to implement and easier to optimize.
Once x86 and similar architectures dominated, the hardware stopped enforcing:
- bounds
- provenance
- validity
And since C mapped perfectly onto that model, it became the dominant systems language.
From that point on:
- pointers became integers
- safety became a software problem
- memory bugs became a security industry
Not because C demanded it, but because the hardware no longer helped.
The Long Detour We Are Now Undoing
For decades, the industry tried to patch this with:
- ASLR
- stack canaries
- DEP
- sanitizers
- fuzzers
All useful. None fundamental.
They treat symptoms, not causes.
Which brings us back, full circle, to the idea that started this story:
A pointer should carry metadata.
A Short Detour: Even x86 Wasn’t Always Flat
Before moving forward, it’s worth correcting one more common simplification.
Even the architecture most associated with “flat pointers”, x86, did not start that way.
In real mode, x86 used segmented addressing:
This meant:
- pointers were effectively split into two components
- address calculation wasn’t trivial
- different segments could overlap
- the same physical memory could be referenced in multiple ways
It wasn’t a capability system, there were no bounds or permissions, but it was a reminder that pointer arithmetic was never universally “just an integer add.”
What changed wasn’t the hardware’s ability to support structure.
What changed was that:
- segmentation was seen as inconvenient
- flat addressing was faster
- compilers and operating systems optimized for simplicity
By the time protected mode and later 64-bit mode arrived, segmentation had been mostly sidelined. The industry standardized on:
Flat memory + software discipline
That decision stuck.
And that’s the world CHERI and FIL-C are now challenging.
Are CHERI and FIL-C fixing the problem?
The Common Idea Behind CHERI and FIL-C
At first glance, CHERI and FIL-C look very different.
One changes the CPU. The other changes the compiler.
But conceptually, they start from exactly the same premise:
A pointer is not an address. A pointer is authority.
Everything else follows from that.
The Shared Heritage: Capability Thinking
Both CHERI and FIL-C descend from the same historical lineage:
- Burroughs descriptors
- Lisp machine object references
- Capability-based operating systems
- Hardware-enforced segmentation
The core idea is simple:
A program should only be able to access memory it was explicitly given access to.
That means a pointer must carry:
- where it points
- how far it can go
- what it is allowed to do
- whether it is still valid
In other words: metadata.
The only real disagreement between CHERI and FIL-C is where that metadata lives.
Cheri: Making Capabilities a Hardware Primitive
CHERI takes the most direct route possible.
It says:
“If pointers are capabilities, the CPU should understand them.”
So CHERI extends the architecture itself.
A CHERI pointer (capability) contains:
- an address (cursor)
- bounds
- permissions
- a validity tag
The tag is critical:
- it is stored out-of-band
- it cannot be forged
- it is cleared automatically if memory is corrupted
- the CPU refuses to dereference invalid capabilities
This means:
- no buffer overflows
- no out-of-bounds accesses
- no forged pointers
- no accidental privilege escalation
And all of this happens without software checks.
The hardware enforces it.
This is not “fat pointers” in the C++ sense. This is architectural memory safety.
Importantly, CHERI preserves C semantics:
- pointers still look like pointers
- code still compiles
- performance is predictable
But the machine simply refuses to execute illegal memory operations.
It’s the return of the capability machine, this time built with modern CPUs, caches, and toolchains.
By design, CHERI enforces only what can reasonably belong to the instruction set, leaving higher-level memory semantics to software.
FIL-C: Capability Semantics Through Compiler and Runtime
FIL-C starts from the same premise:
“C pointers need metadata.”
But instead of changing the hardware, it changes the compiler and runtime.
This choice allows FIL-C to enforce stronger guarantees than CHERI, but at the cost of changing not only pointer representation, but also object lifetime and allocation semantics.
In FIL-C:
- pointers become InvisiCaps
- bounds are tracked invisibly
- provenance is preserved
- invalid accesses trap
From the programmer’s point of view:
- it’s still C
- code still compiles
- the ABI mostly stays intact
From the runtime’s point of view:
- every pointer has hidden structure
- every access is validated
- dangling pointers are detected
FIL-C and CHERI start from the same idea: pointers as capabilities, but deliberately apply it at very different semantic depths.
At this point, the similarity ends.
While CHERI limits itself to enforcing spatial safety and capability integrity, FIL-C necessarily goes further. In order to provide temporal safety, FIL-C must change the object lifetime model itself.
In FIL-C, deallocation is decoupled from object lifetime: freed objects are often quarantined, delayed, or kept alive by a garbage collector. Memory reuse is intentionally conservative, because temporal safety cannot coexist with eager reuse.
This is not an implementation choice but a semantic requirement, and it has consequences that go well beyond pointer representation.
The Reality Check: It’s a Runtime, Not Just a Compiler
It is important to distinguish FIL-C from a simple “safe compiler”. Because it enforces temporal safety via an object lifetime model, it must bypass standard allocators like glibc. This means the high-performance concurrency optimizations (arenas, caches) that developers expect are gone, replaced by a managed runtime.
Furthermore, because FIL-C requires this complex runtime support, it is currently a user-space tool. Using it to build, for example, a kernel like Linux is architecturally unfeasible.
For standard userspace applications, the trade-offs can be summarized as follows:
| Aspect | CHERI | FIL-C |
|---|---|---|
| Enforcement | Hardware | Software |
| Pointer metadata | In registers & memory | In runtime structures |
| Performance | 2%-5% overhead | 50%–200% overhead |
| Deployment | Requires new hardware | Works today |
The higher cost of FIL-C is not primarily due to pointer checks, but to the changes required in allocation, lifetime management, and runtime semantics to enforce temporal safety.
CHERI makes the CPU safe. FIL-C makes the language safe.
Same Idea, Two Execution Models
CHERI and FIL-C are not competitors. They are two implementations of the same philosophy.
They both assert that:
- pointer provenance matters
- bounds must be enforced
- safety must be deterministic
- memory errors are architectural, not stylistic
They differ only in where that logic lives.
You can think of it this way:
- CHERI -> capabilities in silicon
- FIL-C -> capabilities in software
- MTE -> capabilities with probabilities
Different tradeoffs. Same destination.
Why This Matters Now: The ELISA Perspective
At first glance, CHERI and FIL-C may look like academic exercises or long-term research projects. But their relevance becomes much clearer when viewed through the lens of ELISA.
ELISA exists for a very specific reason: Linux is increasingly used in safety-critical systems.
That includes:
- automotive controllers
- industrial automation
- medical devices
- aerospace and avionics
- robotics and energy infrastructure
And Linux, for all its strengths, is still fundamentally:
A large C codebase running on hardware that does not enforce memory safety.
The Core Tension ELISA Faces
ELISA’s mission is not to redesign Linux.
It is to:
- make Linux usable in safety-critical contexts
- support certification efforts (ISO 26262, IEC 61508, etc.)
- improve predictability, traceability, and robustness
- do this without rewriting the kernel
That creates a fundamental tension:
- Linux is written in C
- C assumes unsafe pointers
- Safety standards assume bounded, analyzable behavior
Most current ELISA work focuses on:
- process isolation
- static analysis
- restricted subsets of C
- coding guidelines
- runtime monitoring
- testing and verification
All valuable. All necessary.
But none of them change the underlying truth:
The C memory model is still unsafe by construction.
Why Cheri and FIL-C Enter the Conversation
CHERI and FIL-C do not propose rewriting Linux.
They propose something more subtle:
Making the existing C code mean something safer.
This matters because they address a layer below where most safety work happens today.
Instead of asking:
- “Did the developer write correct code?”
They ask:
- “Can the machine even express an invalid access?”
That’s a fundamentally different approach.
CHERI in the ELISA Context
CHERI is interesting to safety engineers because:
- It enforces memory safety in hardware
- Violations become deterministic faults, not undefined behavior
- It supports fine-grained compartmentalization
- It aligns well with safety certification principles
But CHERI is also realistic about its scope:
- It requires new hardware
- It requires a new ABI
- It is not something you “turn on” in existing systems
Which means:
Cheri is not a short-term solution for ELISA, but it is a reference model for what correct looks like.
It provides a concrete answer to the question: “What would a memory-safe Linux look like if we could redesign the hardware?”
FIL-C in the ELISA Context
FIL-C sits at the opposite end of the spectrum.
It:
- runs on existing hardware
- keeps the C language
- enforces safety at runtime
- integrates with current toolchains
This makes it immediately relevant as:
- a verification tool
- a debugging platform
- a reference implementation of memory safety
- a way to experiment with safety properties on real code
But it also comes with trade-offs:
- performance overhead
- increased memory usage
- reliance on runtime checks
So again, not a drop-in replacement, but a valuable experimental lens.
The Direction Is Clear (Even If the Path Is Long)
The real contribution of CHERI and FIL-C is not that they make C safer by rewriting it.
It is that they show memory safety can be improved by changing the semantics of pointers, while leaving existing code largely untouched.
This distinction matters.
Large systems like Linux cannot realistically be rewritten. Their value lies in the fact that they already exist, have been validated in the field, and continue to evolve. Any approach that requires wholesale code changes, new languages, or a redesigned programming model is unlikely to be adopted.
CHERI and FIL-C take a different approach. They act below the source level:
- redefining what a pointer is allowed to represent
- enforcing additional semantics outside application logic
- turning undefined behavior into deterministic failure
In doing so, they demonstrate that memory safety can be introduced beneath existing software, rather than imposed on top of it.
That insight is more important than either implementation.
It shows that the path forward for Linux safety does not necessarily run through rewriting code, but through reintroducing explicit authority, bounds, and permissions into the way memory is accessed, even if this is done incrementally and imperfectly.
Looking Forward
Neither CHERI nor FIL-C is something Linux will adopt tomorrow.
CHERI depends on hardware that is not yet widely available and will inevitably influence ABIs, compilers, and toolchains. FIL-C works on current hardware, but with overheads that limit its use to specific contexts.
What they offer is not an immediate solution, but a reference direction.
They suggest that meaningful improvements to Linux safety are possible if we focus on:
- enforcing memory permissions more precisely
- narrowing the authority granted by pointers
- moving checks closer to the hardware or runtime
- minimizing required changes to existing code
This leaves room for intermediate approaches: solutions that do not redefine the language, but instead use existing mechanisms, such as the MMU, permission models, and controlled changes to pointer usage, to incrementally reduce the scope of memory errors.
In that sense, CHERI and FIL-C are less about what to deploy next and more about what properties future solutions must have.
They help clarify the goal: make memory access explicit, bounded, and enforceable… without rewriting Linux to get there.
No comments:
Post a Comment