Microsoft has opened developments related to the CHERIoT (Capability Hardware Extension to RISC-V for Internet of Things) project, aimed at blocking security problems in existing C and C++ code. CHERIoT offers a solution to protect existing C/C++ codebases without having to refactor them. Protection is implemented through the use of a modified compiler that uses a special extended set of processor instructions (ISA) provided by the processor and monitoring memory access at the hardware level, checking the correctness of working with pointers and providing isolation of code blocks.
The project was created with the understanding that the low-level nature of the C language becomes a source of memory bugs, leading to problems such as buffer overflows, access to already freed memory, pointer dereferencing, or double freeing. Practice shows that even large corporations such as Google and Microsoft, which have a strict change review policy and use modern development methods and static analysis tools, cannot guarantee the absence of errors when working with memory (for example, about 70% of vulnerabilities in Microsoft and Google are caused by unsafe memory handling).
The problem can be solved by using programming languages ββthat guarantee safe work with memory, or bindings with additional checks, for example, by using MiraclePtr (raw_ptr) instead of ordinary pointers, which performs additional checks for accessing freed memory areas. But such methods are more suitable for new code, and it is quite problematic to rework existing C/C++ projects, especially if they are intended to run in resource-constrained environments, such as embedded systems and IoT devices.
CHERIoT hardware components are designed as a microcontroller based on the RISC-V architecture, implementing the secure CHERI (Capability Hardware Extension to RISC-V) processor architecture, providing a βcapabilityβ-based managed memory access model (each memory read and write operation is authorized) . Based on the instruction set architecture (ISA) provided in CHERIoT, a programming model is built that guarantees the safety of working with memory at the level of individual objects, provides protection against accessing already freed memory and implements a lightweight memory access isolation system. The specified protection programming model is directly reflected in the C/C++ language model, which allows it to be used to protect existing applications (only recompilation and launch on hardware that supports ISA CHERIoT is required).
The proposed solution allows you to block errors that cause out of bounds of an object in memory, does not allow substitution of pointers (all pointers must be generated from existing pointers), monitors memory access after release (any access to memory by an incorrect pointer or a pointer referring to a freed object results in an exception being thrown). For example, the use of CHERIoT allows, without making changes to the code, to implement automatic bounds checking, tracking the lifetime of memory areas and ensuring the integrity of pointers in components that process untrustworthy data.
The project includes a specification for an extended CHERIoT instruction set architecture, a reference implementation of a 32-bit RISC-V CPU with ISA CHERIoT support, and a modified LLVM toolkit. CPU prototype diagrams and hardware block descriptions in Verilog are distributed under the Apache 2.0 license. The Ibex core from the lowRISC project is used as the basis for the CPU. The CHERIoT ISA code model is defined in the Sail language and distributed under the BSD license.
Additionally, a prototype real-time operating system CHERIoT RTOS is proposed, which provides the ability to isolate compartments (compartment) even on embedded systems with 256 MB of RAM. The CHERIoT RTOS code is written in C++ and distributed under the MIT license. In the form of compartments, the basic components of the OS, such as the bootloader, scheduler, and memory allocation system, are designed.
A compartment in CHERIoT RTOS is an isolated combination of code and global variables, which resembles a shared library, but unlike the latter, it can change its state (mutable) and run in a separate security context. No code from outside can transfer control to code in a compartment and access objects, except by accessing specially defined entry points and using pointers to objects explicitly passed when calling another compartment. Code and global objects in a compartment are guaranteed integrity and confidentiality.
Source: opennet.ru