[WIP][not for GCC main branch] CHERI/Morello capabilities in GCC

[Matthew Malcomson <Matthew.Malcomson@arm.com>]

Hello,

We're working on adding CHERI capability support to GCC, specifically focusing
on targetting the experimental Morello architecture.  The eventual aim
is to help bring up a GNU system on the upcoming Morello boards.
Morello is an integration of the CUCL CHERI (Capability Hardware Enhanced RISC
Instructions) protection model into the ARMv8-A architecture.
https://www.arm.com/blogs/blueprint/digital-security-by-design
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Our current status is very much work-in-progress, but to add visibility about
the project to those that are interested, and to ease collaboration with those
we're working closely with, we are pushing the work to a branch in the ARM
vendor area of the GCC main repo.
It is under refs/vendors/ARM/heads/morello.

We do intend to split this into a coherent patch series at some point in the
future as we would appreciate feedback on our approach from the community, but
are not focusing on this yet.  This email is just about mentioning that we are
working on such a project rather than asking for opinions on the approach (since
we have other goals for the short term and creating a meaningful sequence of
commits that communicates intention is quite a bit of work).

To mention, we are notably further along on this project than our first commit
would indicate.  There is a delay between our internal work and making things
public.

For those that are interested we present a *very* high-level description of our
implementation below:

- Capabilities are new hardware features.
  They are logically an integral value, a hardware-maintained validity bit, and
  some metadata.  This is usually a pointer where the integral value is an
  address value (that is not always the case for uintptr_t and intptr_t).
  If the validity bit is not set then no capability pointer can be used (no
  matter what the metadata).  This validity bit can not be set by software
  directly, rather the only way to get a capability with a set validity bit is
  to derive it from another valid capability.

- Our first step is to introduce the concept of capabilities.
  We are most of the way towards this goal.  Here we can act as if generating
  code for a capability-enabled AArch64 architecture before emitting plain
  AArch64 code at the very last step.  This is enabled by a target-specific flag
  `-mfake-capability`.

- A capability is indicated by having a capability MODE (which is a new mode class).
  (either as the mode of the value in RTL, or under the TYPE_MODE of a type in
  TREE/Gimple). Hence a pointer under TREE is described in the same way as usual
  except for having a TYPE_MODE of CADImode (CApability-DImode).

- Some operations do not make sense for capabilities.
  These operations are disabled for capabilities.
  E.g. a basic PLUS can not be made on a capability in RTL since the operation
  requires all modes of operands to be the same and there is no concept of
  adding two capabilities together.

  - Most complex operations on address values should be via casting to an
    integral.
    To do more complex arithmetic on capabilities it is expected that the
    compiler should extract the address value from the capability, perform the
    operations on that address value (which is just an integral value), and
    finally generate a new capability with the old metadata and new value.

Authors of the branch so far:
  Alex Coplan <alex.coplan@arm.com>
  Dennis Zhang <dennis.zhang@arm.com>
  Matthew Malcomson <matthew.malcomson@arm.com>
  Stam Markianos-Wright <stam.markianos-wright@arm.com>

GCC Implementation Design:
  Richard Sandiford <richard.sandiford@arm.com>