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

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

[Matthew Malcomson]

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>

[WIP][not for GCC main branch] CHERI/Morello work in GCC update.

[Matthew Malcomson]

Hello,

In our last email we mentioned that there was work not yet going upstream.
This is to mention that the work that was still internal at that stage has now
gone up to the vendor branch.

The main difference after this change is that our initial work of adding the
concept of CHERI capabilities to GCC has been completed for the C frontend.

What we mean by this is that we believe the compiler at this stage should
compile as much C source correctly as the compiler at the point we branched off,
minus those features that we have disabled for now.

These features have been disabled just for time pressure, our focus is to
help bring up a GNU system on the upcoming Morello boards (especially focussed
on Glibc and the Linux kernel) and we have left working on the C++ frontend and
many optimisations (e.g. capabilities as induction variables, value ranges on
capabilities, OpenMP and OpenACC, the sanitizers) for now in order to provide
something useful for others working on glibc and the kernel as early as possible.

This commit also includes some initial progress towards Pure Capability codegen,
which appears to be able to compile some simple programs to pure capability
assembly even though there are large chunks of work left to do in that area.


Authors of this commit:
  Stam Markianos-Wright <stam.markianos-wright@arm.com>
  Alex Coplan <alex.coplan@arm.com>
  Matthew Malcomson <matthew.malcomson@arm.com>

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

________________________________
From: Matthew Malcomson
Sent: 22 July 2021 17:00
To: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Cc: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>; Richard Earnshaw <Richard.Earnshaw@arm.com>; Vidya Praveen <vidyapraveen@arm.com>; Luis Machado <Luis.Machado@arm.com>; Richard Sandiford <Richard.Sandiford@arm.com>; Szabolcs Nagy <Szabolcs.Nagy@arm.com>; Carlos Seo <Carlos.Seo@arm.com>; Luis Machado <luis.machado@linaro.org>; Silviu Baranga <Silviu.Baranga@arm.com>; Alex Coplan <Alex.Coplan@arm.com>; Stam Markianos-Wright <Stam.Markianos-Wright@arm.com>; jessica.clarke@cl.cam.ac.uk <jessica.clarke@cl.cam.ac.uk>; robert.watson@cl.cam.ac.uk <robert.watson@cl.cam.ac.uk>; Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>; alexander.richardson@cl.cam.ac.uk <alexander.richardson@cl.cam.ac.uk>
Subject: [WIP][not for GCC main branch] CHERI/Morello capabilities in GCC

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>