Provenance

Two pointers can contain the same address but not carry the same authority. One may have been derived from a valid capability for an allocation. The other may be an integer that happens to equal that address. CHERI preserves this distinction.

Provenance is the relationship between a pointer or capability and the authority from which it was validly derived. It answers “Why is this reference allowed to access that object?” as well as “Which number does it contain?”

Authority follows derivation

Suppose an allocator holds a capability for a heap region and returns a smaller capability for one object:

Heap authority:       [--------------------------------]
Allocated object:             [------]
Derived field:                  [--]

The object capability is valid because it was derived within the heap capability’s range and permissions. The field capability carries no more authority than the object capability.

If code later learns the numeric address of another heap object, that number does not provide the tagged capability needed to access it.

Provenance is not a visible history log

CHERI implementations do not need to store a list of every capability operation. The protected tag, bounds, permissions, and architectural derivation rules preserve the security consequence of provenance: ordinary computation cannot manufacture new valid authority from raw data.

The term also appears in programming-language discussions, where compilers reason about which object a pointer may legally refer to. CHERI hardware and a C or C++ compiler must use a compatible pointer model so that optimisation does not contradict the architectural authority rules.

Pointer-to-integer conversion

Legacy code often converts pointers to integers for hashing, alignment, tagging, logging, or storage. On a conventional architecture, converting the integer back may recreate an address that the processor will use as a pointer.

On CHERI, the integer representation does not contain all capability metadata or the protected tag. A valid round trip may require retaining capability provenance through a platform-defined representation or deriving the new address from an existing capability.

The safe rule is:

• keep references as pointer or capability types
• use uintptr_t only for documented address-level operations
• do not expect an arbitrary integer to create authority
• do not serialise capabilities as portable addresses

Compiler diagnostics during a pure-capability port often reveal code that violated these rules implicitly.

Why integer addresses are still useful

Addresses remain useful for logging, comparison under documented rules, file offsets, device protocols, and data structures that refer to positions rather than live memory authority.

The design improvement is to distinguish an identifier or offset from a capability. When software receives an offset from an untrusted source, it validates the value and derives a bounded capability from authority it already holds. The untrusted value chooses within an authorised region; it does not supply the authority itself.

Provenance across interfaces

When a capability crosses a function or compartment boundary, the receiver gains the authority it carries. Interface review should therefore ask:

• Which original capability was used to derive it?
• Were bounds narrowed to the intended object?
• Were unnecessary permissions removed?
• May the receiver retain or delegate it?
• Does the object remain alive for the full permitted use?

This makes authority flow reviewable in a way that a list of integer addresses is not.

Important limits

• Provenance does not prove that application logic chose the right object.
• A valid capability can be over-broad if its source authority was over-broad.
• Provenance and tags do not automatically revoke stale capabilities after free.
• Language rules, compiler implementation, application binary interface (ABI), and hardware behaviour must align.
• Devices and direct-memory-access (DMA) engines need system designs that preserve or mediate capability authority.

Provenance is why Tags & Validity and monotonic derivation matter. Together they prevent “knowing the address” from becoming “owning the authority”.