Capabilities In CAP, CHERI, And Morello

At the recent Arm DevSummit, one of the presentations mentioned CHERI and the Arm Morello board in passing. This was in the context of using capabilities (perhaps) in some future Arm processors to increase the amount of memory safety, and to protect against vulnerabilities like Spectre and Meltdown. I’d never heard of either, so I was intrigued and decided to look into the details.

But the first question you might have is “what is a capability?” Like many terms in computer science, it is used in a technical sense that only has a tenuous connection to its meaning in everyday life.

The easiest way to explain it is with an analogy to Microsoft’s OneDrive or Dropbox. You can create a reference to a file, which is a long string of characters that embeds which file it is and a lot of security. This gives you a long string of characters that you can email or text to anyone. They can then access the file. The security bits give them permission to do some things to the file (read it, write it, etc). It is not necessary to have a lot of other security schemes in parallel (such as usernames and passwords). If you have the long string, you can access the file. That long string is a capability for the file. Another important aspect of this analogy is that you don’t need to be some sort of superuser like “root” or the IT department to create the string in the first place.

In the computer architecture sense, a capability gives you access to some area of memory, in much the way that base-limit registers do. But base-limit registers require the operating system to set them up in privileged mode. In the world of capabilities, you don’t need any special privilege to create a capability, and so there is actually no need for a privileged mode. But in the modern world, operating system and hypervisors are not going away, so a more nuanced approach is required.

The CAP computer

When I was a computer science undergraduate at Cambridge University (technically in what was called the Computer Laboratory at the time), one of the research projects was the “capability machine” or “CAP Computer.” The project was headed by two people. First, Maurice Wilkes, one of the members of the team that designed EDSAC, the world’s first programmable digital computer, and the head of the CS department during my year there. The other was Roger Needham, my operating system lecturer, who would go on to be head of the department and then left to head up Microsoft’s Cambridge research lab. If you want to read a lot about the CAP Computer, then they wrote a book about it: The Cambridge CAP Computer and its Operating System (the link is to a pdf of the book archived at Microsoft).

Computers have had some form of memory protection for a long time (except for the simplest microcontrollers). Typically, a segment is defined by an address, a length, and some permissions as to what can be done with that part of memory. Attempts by a program to access outside the memory will get a fault (“core dumped”). But to set up those segmentation values can only be done by the operating system. For one program to share memory with another requires still more operating system features to be created. There’s no way for one program to simply pass a capability for the memory to another program, without the operating system needing to be involved. The CAP approach is different. There is no need for special functions in the operating system to handle this sort of thing and, in fact, the operating system isn’t especially privileged compared to user programs.

You can read the whole book if you really want to go deep into the CAP machine, but here’s a paragraph that explains the motivation for capabilities:

The conventional system with a privileged mode enables facilities for memory protection to be put at the disposal of the writer of the operating system. Similar facilities cannot, however, be put at the disposal of the designer of a subsystem (for example, a transaction processing subsystem, or a real time subsystem) which will run under the main operating system unless he is allowed to incorporate part of his subsystem within the operating system.

Anyway, this is not a post going into all the details of a fifty-year-old long-forgotten computer. Let’s look at a more up-to-date project based on capabilities.

CHERI

CHERI stands for Capability Hardware Enhanced RISC Instructions. It is a modern project, also part of the Cambridge Computer Laboratory. The aim is that it:

…extends conventional processor Instruction-Set Architectures (ISAs) with architectural capabilities to enable fine-grained memory protection and highly scalable software compartmentalization. CHERI’s hybrid capability-system approach allows architectural capabilities to be integrated cleanly with contemporary RISC architectures and microarchitectures, as well as with MMU-based C/C++- language software stacks.

Unlike the CAP computer, which had novel hardware, required its own compilers, and its own operating system, CHERI is designed to extend existing architectures with capabilities, but without having to throw out all the existing processors and operating systems. It is a more incremental approach.

There is a fairly detailed report (40-page PDF) called An Introduction to CHERI available. It is dated September 2019, so this is fairly current work. In the introduction, they summarize what they have achieved:

• ISA changes to introduce architectural capabilities, hardware-supported descriptions of permissions that can be used, in place of integer addresses, to refer to data, code, and objects in protected ways
• New microarchitecture demonstrating that capabilities can be implemented efficiently in hardware, including support for efficient tagged memory to protect capabilities in memory, and compressed capabilities to reduce memory overhead
• Formal models of CHERI-extended ISAs, used as the architecture definition, as readable documentation, for architecture design exploration, for automatic construction of executable ISA-level simulators, for automatic test generation, and for mechanized verification of formal statements and proofs of the architecture’s security properties
• New software construction models that use capabilities to provide fine-grained memory protection and scalable software compartmentalization
• Language and compiler extensions to use capabilities in implementing memory-safe C and C++, and Foreign Function Interfaces (FFIs) for higher level managed languages
• OS extensions to use (and support application use of) fine-grained memory protection (spatial, referential, and (non-stack) temporal memory safety) and abstraction extensions to support scalable software compartmentalization

Here’s how a 128-bit CHERI Concentrate capability is represented:

The Arm Morello board

Arm has been working closely with the CHERI team. In October 2019 (about a year ago), Arm announced A Safer Digital Future by Design. In that post, Arm laid out one of the reasons for all the interest in capabilities:

Recent research by Matt Miller of Microsoft has shown that 70% of vulnerabilities addressed through a security update each year continue to be memory safety issues. The hardware capability technology used in CHERI, and in the Arm prototype architecture, combine the following: references to memory locations (i.e., pointers) with limits as to how the references can be used; the address ranges that they can use to access; and which functionality they can use to access.

Arm also announced:

Morello, an experimental CHERI-extended, multicore, superscalar ARMv8-A processor, system on chip (SoC), and prototype board to be available from late 2021.

Here’s a block diagram of the chip. Morello will be based on Arm’s existing Neoverse N1 platform and CPU. This is roughly an Arm A76 with an enhanced server-class memory subsystem.

In September 2020 (so just a couple of months ago), Arm published its Morello architecture specification, a fully elaborated integration of the CHERI protection model into the ARMv8-A architecture.

Going forward

Right now, there are lots of moving parts, but Arm seems serious about using the ideas of CHERI to improve the memory security of its processors. I’m an interested observer, having learned about capabilities back when I first studied computer science. They seemed like an elegant idea, but since microprocessors never implemented them (some older mainframes did) they seemed like a dead end. But now, with CHERI and Morello, and serious commitment from Arm, perhaps they will turn out to be an idea whose time has come.