|ARM Ships Morello Board - The Secure Hardware Of The Future|
|Written by Harry Fairhead|
|Friday, 21 January 2022|
ARM is now shipping the first version of a new compartmentalized, secure microprocesser called Morello that is the first fruit of the UK government's Digital Security by Design project.
Morello is the first high-performance implementation of CHERI extensions. which provides fine-grained spatial memory safety at a hardware level. It is a key part of a research program that has the potential to radically change the way processors are developed and programmed in the future to improve built-in security.
When ARM was awarded £36 million for this project in October 2019, Richard Grisenthwaite, ARM chief architect stated:
"Our first step is to create prototype hardware, the Morello Board, as a real-world test platform for prototype architecture developed by ARM that uses the University of Cambridge’s CHERI protection model. It will enable industry and academic partners to assess the security benefits of foundational new technologies we’re making significant investments in."
The major milestone just achieved is the availability of prototype SoCs (systems on chips) which are now handed over to security specialists, software companies, tools developers and leading academic institutions to test, write code and collaboratively provide critical feedback over a period of two and a half years to identify whether Morello is a viable security architecture for the future.
Arm's Morello Board is based on an Armv8.2-A processor adapted from the ARM Neoverse N1 chip and implements an architecture called CHERI (Capability Hardware Enhanced RISC Instructions) developed over the past decade by researchers at the University of Cambridge with the aim of mitigating memory safety vulnerabilities at a hardware level.
The hardware capability technology that is used in CHERI and in the ARM prototype architecture combines references to memory locations. These act as pointers, with limits on how the references can be used. These limits relate to the address ranges and functionality that the references can be used to access, resulting in "compartmentalization" which isolates different parts of critical code into individual ‘walled’ areas:
Microsoft's Portmerion Project, which also encompasses Project Verona, which aims to build a safe language with first-class support for compartmentalization, see Is Microsoft Planning To Replace Rust? is among the recipients of the Morello Board.
Writing on the Microsoft Security Response Center Blog, Saar Amar explains how CHERI strengthens security:
Every load or store instruction and every instruction fetch must be authorized by an architectural capability. Load and store instructions take a capability as the base instead of an integer address. The capability both identifies an address and grants access to a range of memory (including permissions, such as read, write, or execute). The ISA provides operations for restricting the rights on a capability (for example, reducing the bounds or removing permissions) but there is no mechanism for increasing the rights without starting from a more powerful capability (capability monotonicity). This includes storing capabilities to memory, where they are protected by a (non-addressable) tag bit and any attempt to overwrite part or all of a capability in memory clears the tag bit and invalidates the capability.
Amar's post goes into a great deal of detail about how CHERI can be used, its limitations and the continuing need for safe languages and now the Morello board is available he writes:
We’re looking forward to being able to prototype Verona’s isolation on Morello as well as exploring faster temporal safety, overall performance for memory-safe code, isolation in minimal-TCB systems and much more. If the Morello program can demonstrate that CHERI meets the performance goals for real-world use then it is a game changer for security, deterministically preventing spatial safety vulnerabilities and (with software support) heap temporal safety bugs, dramatically reducing the set of bugs that become exploitable as for anything other than denial of service.
We tend to think that security is a software problem - we are responsible for poor code. This is true up to a point, but recent vulerabilities such as Spectre, Meltdown and Rowhammer demonstrate that we also need hardware that doesn't leak information between processes. Until recently designing a processor was mostly about improving performance. Perhaps now hardware designers will start to address the problem of security without damaging performance.
|Last Updated ( Friday, 21 January 2022 )|