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>