Software Security OS Porting to CHERI - A Secure By Design Approach

CHERI is a hardware-software capability-based security architecture
that offers memory safety and scalable software compartmentalisation.
This protects against 70% of software vulnerabilities according to a
recent study by Microsoft. In this talk, I am describing what
CHERI is, the problems it's trying to solve, and my research work on
CHERI in the area of embedded systems and industrial applications.
This includes applications of CHERI in FreeRTOS, Linux, and seL4.

1. Software Security Implementations using CHERI - A Secure By Design Approach Hesham Almatary NTU, 7 August 2024

2. Outline

3. Software Security

4. What is CHERI? Hardware-software capability-based architecture Been under development and research since 2010 by University of Cambridge and SRI Main problems it is trying to address: Memory Safety: spatial and temporal, deterministic, compatible Software Compartmentalisation : scalable Prototypes on RISC-V and Arm (Morello) Software ecosystem: LLVM, CheriBSD , Morello Linux, CheriFreeRTOS , CHERIoT etc. Core principles Intentionality Least privilege Source-code compatibility

5. Starting point: CHERI on 64-bit systems Hardware knows about pointers Pointers carry bounds Pointers carry permissions Pointers can’t be created from thin air All guarantees are deterministic No guarantees rely on secrets All memory access instructions require a valid pointer operand

6. How does CHERI work Capabilities extend integer memory addresses Metadata (bounds, permissions, …) control how they may be used Guarded manipulation controls how capabilities may be manipulated; e.g., provenance validity and monotonicity Tags protect capability integrity/derivation in registers + memory Address space 128-bit capability v 1-bit tag permissions Bounds compressed relative to address otype 64-bit address Upper bound Lower bound Pointer address Memory allocation

7. How does CHERI work Hardware: Double register size New CHERI instructions Tagged memory Hardware exceptions Software: Pointers: hybrid or purecap (CHERI C) Toolchain has to support CHERI capabilities for C/C++ Pointers are capabilities: bounds, permissions, types, tags, etc. Software has to comply with CHERI C guidelines Operating systems have to save/restore CHERI capability registers Linkers and loaders have to derive/create CHERI capabilities Every pointer is a capability: globals, stack pointers, functions, buffers, heap, etc. Compartmentalisation

8. CHERI C Guidelines Pointers are unforgeable capabilities Pointers are not integers: sizeof (void *) != sizeof (long) Minimum alignment for pointers is sizeof (void *) Provenance: pointers are only derived from other pointers uint32_t * mmio_region = (uint32_t *) (0xc0000000) - WRONG - Provenance violation An OS or loader should create capabilities for MMIO regions Code that performs bitwise arithmetic between uintptr_t is prone to error uintptr_t mutex_value = FLAG | ( uintptr_t )( curthread ) - WRONG - Provenance loss Additional implications for code that makes assumptions about the shape of a pointer Monotonicity: A derived pointer cannot extend bounds or permissions A memory allocator should set bounds on capabilities Further reading: CHERI C/C++ Programming Guide https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf

9. CHERI/CompartOS Software Compartmentalisation Fine-grained decomposition of a larger software system into isolated modules to constrain the impact of faults or attacks Goals is to minimize privileges yielded by a successful attack, and to limit further attack surfaces Usefully thought about as a graph of interconnected components, where the attacker’s goal is to compromise nodes of the graph providing a route from a point of entry to a specific target CheriFreeRTOS components and the application execute in compartments. CHERI contains an attack within TCP/IP compartment, which access neither flash nor the internals of the software update (OTA) compartment.

10. CompartOS – A CHERI compartmentalisation model

11. CompartOS – A CHERI compartmentalisation model Anything that could be put in a library could be a compartment: From a single function or variable to thousands New GPREL addressing mode Source files and optional security policies are fed the the CompartOS -aware build system and toolchain. Build output is linkage modules that could be dynamically loaded at run-time

12. CompartOS – A CHERI compartmentalisation model Trampolines – protection domain switch Simply wrapped function calls Capability table per compartment Defines the protection domain

13. Porting different OS designs to CHERI Three different OS designs RTOSes – single privilege ring, no MMU Microkernels – privilege rings and MMU, drivers in userspace . Monolithic UNIX – privilege rings and MMU, services and kernel modules in kernel By Wooptoo - Own work, Public Domain, https:// commons.wikimedia.org /w/ index.php?curid =4265836

14. CheriFreeRTOS An implementation of CHERI’s memory safety and CompartOS model Most widely used open-source RTOS Modular with third-party libraries

15. CheriFreeRTOS – What does it add?

16. CheriFreeRTOS – Performance Performance overheads of sending 8 megabytes file to an FTP server

17. CheriFreeRTOS – C/C++ source-code compatibility

18. CheriFreeRTOS – Performance CompartOS ’ protection-domain crossing is 95% faster than MPU-based IPC

19. CheriFreeRTOS – Real-world demos TCP/IP, FTP, CLI, servers Performance benchmarking Compatibility Amazon’s OTA Over 100k LoC Complete end-to-end demo Compatibility Cyber-physical automotive Fault handling Safety-critical systems CheriFreeRTOS components and the application execute in compartments. CHERI contains an attack within TCP/IP compartment, which access neither flash nor the internals of the software update (OTA) compartment.

20. CHERI-Linux – Overview A proof-of-concept application of CHERI’s memory-safety and CompartOS ’ software compartmentalisation model in a big system like (MMU-less) Linux

21. CHERI-Linux – Overview

22. CHERI-Linux – Why not just use MMU?

23. CHERI-Linux – Compartmentalisation – CHERI C

24. CHERI-Linux – Userlevel – Memory Safety Number of inserted/deleted lines to secure embedded MMU-less Linux using CHERI

25. seL4 seL4 is a secure microkernel – formally verified Gives isolation guarantees between user-level protection domains No, memory safety, guarantees at user-level

26. CHERI-seL4 - Ideal goal Supporting run-time CHERI C user-space enhances security Currently on-going, but soon to be open-source RFC: https://sel4.atlassian.net/browse/RFC-15

27. CHERI-seL4 – WIP LoC changes

28. Conclusions

29. Resources Watson, Robert NM, et al. Capability hardware enhanced RISC instructions: CHERI instruction-set architecture (version 9). No. UCAM-CL-TR-987. University of Cambridge, Computer Laboratory, 2023. Almatary , Hesham, et al. " CompartOS : CHERI compartmentalization for embedded systems."  arXiv preprint arXiv:2206.02852 (2022). Almatary , Hesham. CHERI compartmentalisation for embedded systems. Diss. 2022. Almatary , Hesham, Alfredo Mazzinghi , and Robert NM Watson. "Case Study: Securing MMU-less Linux Using CHERI." SE 2024-Companion. Gesellschaft für Informatik eV, 2024. CHERI Website -- https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

30. [email protected]

31. Acknowldgment Thanks for the CHERI group and David Chisnall for permitting usage of some of their slides