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. It is not an exclusive list of potential projects, and you should reach out to the researchers identified here for further ideas, or to propose your own.
CHERI background
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 fifteen years, and as part of an expanding set of industrial collabroations, this has led to the creation of Arm's Morello prototype, a multi-GHz, multicore CHERI implementation integrated with the 64-bit Armv8-A ISA, as well as multiple announced tape-outs of CHERI-extended RISC-V chips suitable for embedded, IoT, and industrial control, such as Microsoft's CHERIoT microcontroller now being productised by SCI Semi, lowRISC, Google, and other vendors. The University and its industrial parners have developed multiple RISC-V-based CHERI application cores and microcontrollers suitable for both research and production use, which can be deployed on FPGA.
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, as we have a large cluster of remotely accessible Morello servers in the West Cambridge Data Centre, whereas those investigating architecture or microarchitecture might choose to use CHERI-RISC-V on FGPA or on QEMU.
Potential student project areas
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 OS, and compartmentalising significant software applications. Past Part III and ACS projects have included extending an OS kernel to use CHERI memory protection internally, testing CHERI integration in the OS 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 more than one of) hardware, software, and formal modeling/proof.
Specific project ideas
Developing more robust CHERI C/C++ code generation and ABIs
Contact: Robert Watson
Today, CHERI C and C++ are focused on robust implementation of language-level reference, spatial, and temporal safety, which includes protecting both language-level and sub-language pointers. This model implements strong language-level memory safety, but in the event of a language-level compromise, and despite the protections for sub-language pointers (such as GOT and stack pointers), there remain many under-exploited opportunities to harden the sub-language environment using CHERI techniques. For example, today CHERI does not perform type checks to make sure that stack pointer registers point to stacks, nor does it type check vtables, GOT pointers, or other pointers to implied data structures in the runtime. It would be relatively easy to change aspects of the ABI and code generation so that those checks were performed as part of function prologues or epilogues, at some cost in terms of additional instructions or memory references.
This project would start by enumerating common exploit techniques dependent on sub-language pointer misuse or manipulation, and explore changes to the compiler, linker, and run-time linker to introduce new checks improving resilience to those techniques. The evaluation would consider the impact on code density, performance across a variety of workloads, security with respect to those techniques, and compatibility impacts. A strong project might propose (and evaluate) architectural extensions to reduce the performance impact of these changes.
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).
CHERI stack temporal safety
Contact: Robert Watson
We have explored various forms of heap temporal safety based on garbage-collection-like revocation techniques, which sweep memory for capabilities to free'd memory before it can be reallocated. Due to the current cost and overall throughput of stack allocation, these techniques are likely unsuitable for stack allocation. This research project would investigate a strawman "true" temporal safety for stacks based on revocation, but also a number of more pragmatic techniques including stack-frame clearing, performing revocation only on escaped pointers and avoiding revocation if no pointers to a frame escape, and so on. Different gradations of temporal safety would be identified, including simple pointer revocation in allocated frames (perhaps via architectural fast tag-clearing extensions) through to full memory clearing of frames, and full memory revocation. Each approach, including the strawman ("ideal semantics") would be prototyped via changes to the compiler and C runtime and evaluated on one or more CHERI-RISC-V cores (e.g., 5-stage pipeline, superscalar) on FPGA.
This project will engage heavily with C-language semantics and practical compiler behavior, as well as require building knowledge about a novel computer architecture. It will be challenging, but should also be very exciting.
Morello Linux PCuABI third-party software support in CheriBSD and Morello Linux
Contact: Konrad Witaszczyk
CheriBSD developed by University of Cambridge and SRI International and Morello Linux developed by Arm are two main operating systems supporting the Arm Morello platform and implementing pure-capability ABIs (CheriABI in CheriBSD and PCuABI in Morello Linux). While CheriBSD provides an extensive set of ~10,000 third-party software adaptations to CHERI, Morello Linux does not ship pre-compiled packages for its end users at the moment. PCuABI support in CheriBSD and QEMU can help to bring more third-party software to Morello Linux and improve PCuABI implementation in Morello Linux as compared to CheriABI in CheriBSD. Rather than a single student project, two independent student projects related to this topic can be proposed that would compose together a third-party package building infrastructure for Morello Linux.
The Morello Linux PCuABI compatibility layer in CheriBSD would provide early access to more advanced CheriBSD features to the CHERI Linux ecosystem, before these features are implemented in a future CHERI Linux kernel. Additionally, it would allow testing software compiled for PCuABI and comparing it against CheriABI. FreeBSD and CheriBSD already implement the Linux binary compatibility layer that can be extended to PCuABI.
QEMU user mode for PCuABI would allow to emulate PCuABI programs on non-Morello hardware and help to build third-party software packages for Morello Linux at a scale similar to the infrastructure used for CheriBSD. In this case, the existing QEMU user mode implementation for CheriABI on CheriBSD would be reused to express logic that is common to both CheriABI and PCuABI.
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, Professor Robert Watson, or Professor Simon Moore for further information.