> often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages The Fil-C project (discussed in [0],[1]) ha

> often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages The Fil-C project (discussed in [0],[1]) has ported many programs to an emulated CHERI-like capability runtime, and shown that capabilities aren't actually that breaking in practice [0]. Another way of using CHERI would be in "Hybrid mode" with most of a program under a single capability, and using other capabilities for compartmentalisation. In a system where you have only memory-safe languages, you'd still sometimes need to run older code from other languages, or code from external sources: and you can't always validate them 100%. A couple operating system projects based on Rust (such as Theseus [1]) solve this by running them in WASM instances. A CHERI capability would be fast hardware-support for bounds-checking access to such a compartment. Also, there is the problem of fast inter-process communication: Copying bytes vs. modifying PTEs — each method with different trade-offs. With CHERI, you could potentially instead pass capabilities, and even share them by writing them in shared memory without involving the kernel. 0: https://fil-c.org/programs_that_work https://fil-c.org/programs_that_work 1: https://www.theseus-os.com/2021/11/01/October-Update-WASM.html https://www.theseus-os.com/2021/11/01/October-Update-WASM.ht...