Microsoft has unveiled developments related to the CHERIoT project (Capability Hardware Extension to RISC-V for Internet of Things), aimed at addressing security issues in existing C and C++ code. CHERIoT offers a solution that protects existing codebases in C/C++ without the need for substantial rewrites. The protection is implemented through a modified compiler that utilizes a special extended set of processor instructions (ISA), enabling hardware-level tracking of memory access, verification of pointer correctness, and isolation of code blocks.
The project is designed with the understanding that the low-level nature of C can lead to memory-related errors, resulting in issues such as buffer overflows, accessing already freed memory, dereferencing pointers, or double freeing of memory. Practice shows that even large corporations like Google and Microsoft, which have strict change review policies and employ modern development practices and static analysis tools, cannot guarantee the absence of memory management errors (for instance, around 70% of vulnerabilities in Microsoft and Google software products are caused by unsafe memory handling).
The problem can be addressed by using programming languages that guarantee safe memory handling, or wrappers with additional checks, for example, by using specialized pointer types like MiraclePtr (raw_ptr) that perform additional checks when accessing freed memory areas. However, such methods are more suitable for new code, and retrofitting existing C/C++ projects can be quite challenging, especially if they are intended to run in resource-constrained environments like embedded systems and Internet of Things devices.
The hardware components of CHERIoT are designed as a microcontroller based on the RISC-V architecture, implementing the CHERI (Capability Hardware Extension to RISC-V) secure processor architecture, which provides a memory access model based on capabilities (each read and write operation to memory is authorized). The provided command set architecture (ISA) of CHERIoT forms a software model that guarantees secure memory operations at the object level, offers protection against access to already freed memory, and implements a lightweight memory access isolation system. This protective software model directly translates into the C/C++ language model, allowing its use to secure existing applications (only recompilation and running on hardware supporting the CHERIoT ISA are required).
The proposed solution allows for blocking errors that cause out-of-bounds access to memory, prevents pointer substitution (all pointers must be derived from already existing pointers), and monitors memory accesses after deallocation (any access to memory through an incorrect pointer or a pointer referring to a freed object generates an exception). For instance, using CHERIoT enables automatic boundary checking, tracking memory region lifetimes, and ensuring pointer integrity in components that handle untrusted data without modifying the code.
The project includes a specification of the extended CHERIoT instruction set architecture, a reference implementation of a 32-bit RISC-V CPU supporting 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 CPU is based on the Ibex core from the lowRISC project. The CHERIoT ISA model code is defined in Sail and is distributed under the BSD license.
Additionally, a prototype of the CHERIoT RTOS real-time operating system has been proposed, offering the capability to isolate compartments even on embedded systems with 256 MB of RAM. The CHERIoT RTOS code is written in C++ and is distributed under the MIT license. Basic components of the OS, such as the bootloader, scheduler, and memory allocation 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
