Safe sharing of CHERI capabilities between POSIX processes

CHERI is an experimental hardware ISA extension that thrives to solve classes of memory safety issues in legacy software. It does so by replacing pointers with "capabilities", which encode and enforce a valid range and access mode for each pointer value. A key point of CHERI is that valid capabilities can not be created ("forged"), but only be derived as a subset of another capability.

When used along with a POSIX process model, capabilities are enforced on the level of virtual addresses. A given address from one process (address space) usually translates to different physical memory, and may have completely different semantical meaning, in a different address space. In general, processes therefore have to be prevented from obtaining capabilities from other processes.

Current implementations of CheriBSD and Cheri Linux therefore categorically disallow reading or writing capabilities to/from shared memory. We see some open issues, though:

• CHERI is meant to support legacy software with no to minimal source code modifications, but all pointers are automatically replaced by capabilities. While in many cases, it makes no logical sense to share pointers between processes, there are cases where doing so is sound and save.
  We want to investigate weather these cases can efficiently be recognized to allow limited sharing of capabilities between processes.

• Often (and currently forced to by CHERI), when working with pointers and shared memory, programmers use offsets and manually add those to different base pointers (/capabilities). This is not only additional manual work, but with CHERI also means that any such index-derived capability will, by default, inherit all permissions of the base capability used. This effectively disabled capability enforcement in these cases.
  We want to investigate whether it is viable to implement the indices as relative capabilities that, when applied to the correct base capability, result in an absolute capability with fine-grained permissions.

• Linux uses a number of mechanisms that try to avoid data copying during RPC for performance reasons (zero copy). So even if capability transfer via copying RPC and explicitly shared memory is disallowed, valid capabilities may still leak between processes via implicitly shared memory.
  We want to investigate wether and how Linux RPC can be made to securely prevent the propagation of capabilities (without considerable performance regressions).

Preliminary work on this (verifying and defining the scope of the issue) has been doe in a previous bachelor thesis. The open issues can be addressed in one or more master theses.