Capability-based addressing

In

• Require capabilities to be stored in a particular area of memory that cannot be written to by the process that will use them. For example, the Plessey System 250 required that all capabilities be stored in capability-list segments.
• Extend memory with an additional bit, writable only in supervisor mode, that indicates that a particular location is a capability. This is a generalization of the use of
  Burroughs large systems, and it was used to protect capabilities in the IBM System/38
  .

The System/38 supported two types of object pointer – authorized pointers, and unauthorized pointers, the former was the platform's implementation of capability-based addressing.^[2] Both types of pointer could only be manipulated using privileged instructions, and differed by whether object authorizations (i.e. access rights) were encoded in the contents of the pointer. Unauthorized pointers did not encode object authorizations, and required the operating system to check the object's authorization separately to determine if access to the object was allowed. Authorized pointers encoded object authorizations, meaning that possession of the pointer implied access, and the operating system was not required to verify authorization separately. Authorized pointers were irrevocable by design - if the object's authorizations were altered, it would not alter the encoded authorizations in any authorized pointers which already existed.

Early versions of the

• 1969:
  System 250 – Plessey
  Company
• 1970–77:
  University of Cambridge Computer Laboratory
• 1978:
  System/38
  – IBM
• 1980: Flex machine – Royal Signals and Radar Establishment (RSRE) Malvern
• 1981: Intel iAPX 432 – Intel
• 2014: CHERI (adds capabilities to existing ISAs for safer programming, even in C and C++)
• 2020: CHEx86
• 2022: ARM Morello (AArch64 with CHERI capabilities)