The final version of the specification for the CHERIoT 1.0 hardware-software platform (Capability Hardware Extension to RISC-V for Internet of Things) has been presented, defining an extension of the instruction set architecture (ISA) for the creation of secure devices. CHERIoT provides hardware capabilities for tracking memory access, checking pointer correctness, and ensuring isolation of code blocks. A stable release of the reference formal model of CHERIoT ISA, defined in Sail, has been published simultaneously. The project's developments are distributed under the BSD license.
The CHERIoT project was created by Microsoft to address security issues in existing code written in C and C++ and to protect such code without the need for rewriting. Protection is implemented through a modified compiler that uses an extended set of processor instructions (ISA) to ensure pointer integrity, boundary checks during memory operations, and to prevent access to freed memory. In 2023, the developments of CHERIoT were opened and transformed into a collaborative project that involved other companies.
The hardware components of CHERIoT are organized as a microcontroller based on the RISC-V architecture, implementing the secure CHERI (Capability Hardware Extension to RISC-V) processor architecture with a capability-based memory access model (each read and write operation to memory is authorized). A software model is built upon the instruction set architecture (ISA) provided in CHERIoT, guaranteeing memory safety at the level of individual objects, protecting against access to already freed memory, and implementing a lightweight memory access isolation system.
The specified software protection model directly reflects in the C/C++ language model, allowing it to be used for existing applications, the protection of which requires only recompilation and execution on hardware that supports the CHERIoT ISA. For instance, the use of CHERIoT enables automatic boundary checking, lifetime tracking of memory areas, and ensuring pointer integrity in components that handle untrusted data, all without making changes to the code.
Among the issues blocked through the use of CHERIoT:
- Out of bounds access in memory;
- Pointer substitution (when using CHERIoT, all pointers must be derived from already existing pointers);
- Accessing memory after freeing (any access to memory through an incorrect pointer or a pointer referencing a freed object leads to an exception when using CHERIoT).
In addition to the specification and formal model, the project is developing a reference implementation of a 32-bit RISC-V CPU Ibex with support for the CHERIoT ISA and a modified LLVM toolchain. The CPU prototype schematics and hardware block descriptions in Verilog are distributed under the Apache 2.0 license. The Ibex core from the lowRISC project serves as the basis for the CPU. Chips ICENI based on the CHERIoT Ibex core are being prepared for mass production, with sales expected next year. Separately, Microsoft is developing the Kudu microcontroller with support for the CHERIoT ISA. Both Ibex and Kudu fully support the CHERIoT 1.0 specification. Work is underway to standardize the CHERI extensions for RISC-V processors within the RISC-V International organization.
Additionally, an FPGA-based platform emulator and a Docker container for developers with pre-installed tools and the Ibex CPU simulator implemented using Verilator are being developed. Furthermore, a prototype real-time operating system CHERIoT RTOS has been prepared based on CHERIoT, providing the capability for compartment isolation even on embedded systems with 256 MB of RAM. The CHERIoT RTOS code is written in C++ and distributed under the MIT license. The basic operating system components, such as the bootloader, scheduler, and memory distribution system, are designed in the form of compartments.
A compartment in CHERIoT RTOS is an isolated combination of code and global variables that resembles a shared library, but unlike the latter, it can change its state (mutable) and run in a separate security context. No external code can transfer control to the code in the compartment or access its objects, except by calling specifically defined entry points and using pointers to objects explicitly passed when invoking another compartment. Integrity and confidentiality are guaranteed for code and global objects within the compartment.
Source: opennet.ru
