CHERI

Cambridge Part II, Part III, and ACS student project ideas - CHERI

This page documents potential student dissertation and research project ideas based on CHERI-related research for University of Cambridge Computer Laboratory students. As with virtual memory, CHERI is an architectural protection model. CHERI extends Instruction-Set Architectures (ISAs) and processors so that software can define policies at run time, including memory protection and isolation. CHERI has very different scaling properties, and target use cases, from virtual memory, however, allowing much finer-grained protection and more efficient software compartmentalisation. The CHERI project has been running for over ten years, and Arm has recently shipped an experimental, high-performance CHERI-based CPU, Morello, with SoC and development board. Microsoft has also recently announced a production-quality embedded RISC-V core implementing CHERI. Student projects would work on Morello, FPGA, and/or ISA-level simulations (i.e., CHERI Qemu), depending on the project's goals. Purely software projects might choose to focus solely on Morello, whereas those investigating architecture or microarchitecture migth use CHERI-RISC-V.

CHERI and potential student project foundations in hardware and software

The CHERI project spans hardware, software, and theory, exploring the interactions between compatibility, performance, and security as we transform the way programs are represented in terms of instruction-set architecture, OS platform, and compilation. Past Part II projects have included designing a small CHERI-enabled RISC-V microcontroller, implementing a floating-point unit, adding CHERI-aware run-time linking to an operating system, and compartmentalising significant software applications. Past Partt III and ACS projects have included extending an OS kernel to use CHERI memory protection internally, testing CHERI integration in the operating system and compiler using tracing, and extending the DTrace debugging facility to work with (and use) CHERI. There are many potential projects to do, in (or spanning) hardware, software, and formal modeling/proof.

Our original CHERI-MIPS hardware stack was based on a home-grown open-source pipelined 64-bit MIPS core, BERI. More recently we have been extending a set of three open-source RISC-V cores, Piccolo (3-stage), Flute (5-stage), and Toooba (superscalar) implemented in Bluespec SystemVerilog (BSV) based on designs from Bluespec and MIT. This new architecture is known as CHERI-RISC-V, and is mature enough to host a range of research and development projects. Our CHERI hardware and software could form the basis of other development and research projects such as exploring potential CHERI interactions with various computation models such as vector computing and machine learning. It would also be interesting to explore the composition of CHERI with other architectural security models such as enclaves, information-flow tracking, and memory versioning.

Our CHERI software stack consists of an assembler, compiler, and linker based on the Clang/LLVM toolchain, as well as LLD debugger, and two CHERI-extended operating systems: CheriBSD (on 64-bit Armv8-a or 64-bit RISC-V, MMU based) and CheriFreeRTOS (32-bit RISC-V, without an MMU). We also have a substantial user application stack, including the FreeBSD UNIX userspace (e.g., including OpenSSH), and open-source applications such as Postgres, nginx, Wayland / KDE, and WebKit. All of these have been extended for fine-grained memory protection; some are also being extended to support compartmentalisation. This software stack could be used at the foundation for a variety of projects including work on new OS primitives (e.g., hypervisor support for CHERI, analysis tools to validate capability delegation), new compartmentalisation models such as in-kernel compartments), compiler features (e.g., exploring CHERI-backed C/C++ type safety not just memory safety, tradeoffs in terms of bounds setting), debugging (e.g., how should a debugger work correctly and securely in a least-privilege environment), or application-level work (how should a major application, such as a web browser, use compartmentalisation? How should language runtimes use architectural memory safety to support higher-level type-safe or managed languages?).

A variety of adversarial activities would also be interesting, to try to identify vulnerabilities in the architecture, hardware, toolchain, and/or software stacks.

Specific project ideas

CHERI memory and trace analysis for visualisation and validation

Contact: Robert Watson

Memory-safe C and C++ software running on CHERI may instantiate, implicitly and implictly, tens or hundreds of thousands of capabilities. Tools able to analyse memory snapshot and execution traces could assist both with validating that specific implementation objectives are met (e.g., with respect to stack or memory-mapping bounds setting, or compartmentalisation), and also to support discovering and understanding application behaviour (e.g., through static or interactive plots and reports on capability use).

Microarchitectural design of new CHERI domain crossing instructions

Contact: Jonathan Woodruff

This project would implement the two experimental instructions described in the CHERI Architecture document in the section titled "Indirect Sentry Capabilities" (see CHERI Architecture v8; upcoming publication). This section describes two domain crossing instruction variants for CHERI which should present interesting tradeoffs in microarchitectural implementation. The first loads a capability pointer from memory directly into the PC, and the second not only does this but also loads a second, adjacent capability pointer into a register. This project would implement examples of these instructions in the Flute (in-order, single-scalar) and/or Toooba (out-of-order, super-scalar) open-source CHERI-RISCV implementations and explore the complexity and cost of adding these unusual instructions to the microarchitecture. There should be some evaluation of performance using micro-benchmarks to demonstrate the value (or lack thereof) of the more sophisticated implementation options.

CHERI Domain Crossing using Simplified Primitives

Contact: Jonathan Woodruff

The primary domain crossing mechanism for compartmentalisation in CHERI has relied on sealing with object types. The shortcoming of this approach is that it requires a type field to be allocated in the capability encoding which is necessarily limited in size, and therefore introduces an awkward necessity to manage this limited typespace. A simpler mechanism has recently been added to the CHERI architecture; Sealed Entry Capabilities (or "Sentries"). These simply unseal and jump to a target capability, granting access to any capabilities embedded with the target instructions. Sentries have the convenient property that their object type space scales with the virtual address space, while bearing the disadvantage of tying together objects and code.

Libcheri is a library used for compartmentalisation which uses the traditional type-based domain crossing instructions. This project would develop an alternative implementation of libcheri based solely on the Sentry mechanism, likely requiring some system of indirection to ensure the integrity of entry tokens distributed to mutually distrusting domains. This project would seek to approach the performance of type-based libcheri for the existing benchmarks to learn where the type-based mechanism might be replaced for this style of compartmentalisation.

Contact details

There are, of course, many other interesting projects that might be done in related areas, and you should feel to talk to us about these as well. Please contact the listed potential supervisor, Dr Robert Watson, or Professor Simon Moore for further information.