Introduction
CHERI Background Material
cite: CHERI Background @RISC-V SIG CHERI
CHERI Talks/Videos
- Motivation for CHERI YouTube video (3-minutes)
- HotChips 2022 - Talk on Morello (CHERI on ARM): YouTube Slides
- CHERI Session at RISC-V Week in Paris Slides
Industry Announcements about CHERI
- ARM Morello (CHERI on ARM) Web site
- Microsoft announce CHERI-RSIC-V embedded core Blog
- Microsoft security analysis of CHERI Report PDF on GitHub
Background Research
More informative introductions:
Questions
Code pointers in Cheri is protected from being corrupted. Can it prevent the code reuse attack also? If not, how to enhance it?
- Code reuse that depends on the corruption of return address might be prevented if ret addr is ‘well protected’.
- Sadly not. Any executable capability in the ‘valid’ set of current process can overwrite the return address on the stack;
Code reuse that depends on the corruption of return address might be prevented if no memory error can be used to overwrite the return address.
- How to prove there is no memory error in CHERI?
- How to prove there is no memory error in CHERI?
Code reuse by data corruption (data oriented programming) might be prevented if data is well protected.
- How to prove there is no memory error in CHERI?
- Code reuse that depends on the corruption of return address might be prevented if ret addr is ‘well protected’.
The heavy and deep motivations of CHERI: Motivations
History
- 2016 v5: Initial in-kernel privilege limitation
- 2017 v6: Exception free domain transition
2019 v7: Temporal memory safety
C language compilation mode where all pointers are capabilities in 2015-ASPLOS 5;
Use of capabilities to implement a safe JNI, 2017-ASPLOS6.
A complete userspace execution environment with CheriABI: 2019-ASPLOS7;
Basics
Address validity vs pointer safety
Address validity associates protection properties with regions of address space, (such as a virtual page), regardless what is stored in the region.
Pointer safety associates protection properties with object references, a higher abstraction over the raw memory regions.
Capabilities
Capability systems are hardware, software, or distributed systems designed to implement the principle of least privilege[^11, ^12].
Capabilities are unforgeable tokens of authority granting rights to objects in the system. They can be selectively delegated between constrained programs to enforce security policies.
Compartmentalization
Software compartmentalization, as known as privilege separation, mitigates vulnerabilities by decomposing applications into isolated components – each granted only the rights it requires to operate.
Compartmentalization granularity describes the degree of program decompositioin. Fine-grained compartmentalization improves mitigation by virtue of the principle of least privilege: attackers must exploit
MMU’s granularity and address validation
process-granularity fault isolation, but
- “When OS kernels act on userspace, e.g., via pointers passed in to system calls, they must act on correct set of physical pages correpsonding to the process.”
conflated protection and translation: the granularity of both is one virtual page. But
- do not scale easily to handle finer-grain protection, and
- do not distinguish virtual addresses from arbitrary integers: while the MMU protects the structure of the virtual memory space, the references to virtual memory are unprotected.
Overview
CHERI Capabilities
- Tags protect capabilities in registers and memory
- Bounds limit range of address space accessible via pointer
- Permissions limit operations, e.g., load, store, fetch
- Sealing for encapsulation: immutable, non-dereferenceable. The seal bit tag is removed from ISAv7. Instead, unsealed capability is redefined as having otype of $2^64 -1$.
- Compressed bounds relative to 64-bit virutal address.
Protection Semantics for Pointers
- Integrity and provenance validity
- ensure that valid pointers are derived from other valid pointers via valid transformations;
- invalid pointers cannot be used
- Bounds prevent pointers form being manipulated to access the wrong object;
- Permissions limit unintended use of pointers; e.g., W^X for pointers;
- Monotonicity prevents pointer privilege escalation; e.g., broadening bounds.
However, bounds and permissions must be initialized correctly by software – e.g. stack allocator, heap allocator, dynamic linker
Two levels of abstraction
(v5:) Cheri allows software privilege to be minimized at two levels of abstraction.
architectural least privilege: memory capability.
- data pointers: against data-oriented vulnerabilities, such as buffer overflows.
- code pointers: support CFI by preventing corruption of code pointers/return addresses.
application-level least privilege: software compartmentalization using object capabilities.
Code pointers
- CHERI: A Research Platform Deconflating Hardware Virtualization and Protection. RESoLVE, 2012. ↩
- The CHERI capability model: Revisiting RISC in an age of risk. ISCA, 2014. ↩
- Fast Protection-Domain Crossing in the CHERI Capability-System Architecture. MICRO, 2016. ↩
- CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. SP, 2015. ↩
- Beyond the PDP-11: Processor support for a memory-safe C abstract machine. ASPLOS, 2015. ↩
- CHERI JNI: Sinking the Java Security Model into the C. ASPLOS, 2017. ↩
- CheriABI: Enforcing Valid Pointer Provenance and Minimizing Pointer Privilege in the POSIX C Run-time Environment. ASPLOS, 2019. ↩
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?