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-wri...@arm.com> Alex Coplan <alex.cop...@arm.com> Matthew Malcomson <matthew.malcom...@arm.com> GCC Implementation Design: Richard Sandiford <richard.sandif...@arm.com> ________________________________ From: Matthew Malcomson Sent: 22 July 2021 17:00 To: gcc@gcc.gnu.org <gcc@gcc.gnu.org> Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Richard Earnshaw <richard.earns...@arm.com>; Vidya Praveen <vidyaprav...@arm.com>; Luis Machado <luis.mach...@arm.com>; Richard Sandiford <richard.sandif...@arm.com>; Szabolcs Nagy <szabolcs.n...@arm.com>; Carlos Seo <carlos....@arm.com>; Luis Machado <luis.mach...@linaro.org>; Silviu Baranga <silviu.bara...@arm.com>; Alex Coplan <alex.cop...@arm.com>; Stam Markianos-Wright <stam.markianos-wri...@arm.com>; jessica.cla...@cl.cam.ac.uk <jessica.cla...@cl.cam.ac.uk>; robert.wat...@cl.cam.ac.uk <robert.wat...@cl.cam.ac.uk>; Ruben Ayrapetyan <ruben.ayrapet...@arm.com>; alexander.richard...@cl.cam.ac.uk <alexander.richard...@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.cop...@arm.com> Dennis Zhang <dennis.zh...@arm.com> Matthew Malcomson <matthew.malcom...@arm.com> Stam Markianos-Wright <stam.markianos-wri...@arm.com> GCC Implementation Design: Richard Sandiford <richard.sandif...@arm.com>
