Lewis Revill

CHERI defines hardware extensions to encode access constraints on pointers, enabling hardware enforcement of such restructions based on metadata stored alongside pointers. There is an ongoing drive to support compiling Rust code in a way that can make use of these extensions.

Doing this provides another layer of protection. We can encode knowledge about provenance validity, bounds and other access restrictions that the compiler (and OS/etc.) knows about in a way the hardware can enforce at runtime. The Rust memory model is famous for being able to enforce these types of restrictions at compile time, but not for unsafe Rust code. Unsafe Rust code needs to be written sometimes, which presents situations which can only be verified at run time. Some other nice benefits could come from this work. For example, runtime bounds checking can now be done by hardware rather than software, and since provenance information is necessary for operations on capabilities, closing gaps where it is not currently preserved forms a part of this work.

This talk is a discussion on what is required for this support, and gives an overview of the state of the various attempts to implement this support.

Nearly 50 years ago on the 20th of July 1969 humans set foot on the moon for the first time. Among the many extraordinary engineering feats that made this possible was the Apollo Guidance Computer, an innovative processor for its time with an instruction set that was thought up well before the advent of C. So 50 years later, why not implement support for it in a modern compiler such as LLVM?

This talk will give a brief overview of some of the architectural features of the Apollo Guidance Computer followed by an account of my implementation of an LLVM target so far. The shortcomings of LLVM when it comes to implementing such an unusual architecture will be discussed along with the workarounds used to overcome them.