I have begun to read the spec which gives a broader picture of CHERI, including compartmentalization.
“As a result, large-scale compartmentalized applications are difficult to design, write, debug, maintain, and extend; this raises serious questions about correctness, performance, and most critically, security.”
That was not our conclusion.
They are complaining about having to pass messages between components.
Page 8:
Specifically, we seek to decouple the virtualization from separation to avoid scalability problems imposed by translation look-aside buffer (TLB)-based Memory Management Units (MMUs), which impose a very high performance penalty as the number of protection domains increases, as well as complicating the writing of compartmentalized software.
We shall see.
Page 12 has a good section describing systems such as Keykos and the demands they put on hardware.
CHERI has a C0 register that holds a capability to the address space of the current process.
Is it protected?
malloc must use it.
Does malloc have more authority so that it can use it?
Page 12:
On current conventional hardware, native applications must be converted to employ message passing between address spaces (or processes) rather than using a unified address space for communication, sacrificing programmability and performance by transforming a local programming problem into a distributed systems problem.
In Keykos one can send a cap for a segment whereupon sender and receiver may share that segment in their respective address spaces.
That all seems the idea behind the 1967 Blaauw box and even earlier MMU designs.
We did not think that we were innovating.
It is the way that Unix has shared libraries since very near the beginning.
In comparison, physically indexed general-purpose CPU caches are several orders of magnitude larger than TLBs, scaling instead with the working set of code paths explored or the memory footprint of data actively being used. If the same data is accessed by multiple security domains, it shares data or code cache (but not TLB entries) with current CPU designs.
Keykos shares TLB entries, memory map table such as page tables and data in cache across protection domains.
Page 13:
Current hardware is intended to provide robust shared memory communication only between mutually trusting parties, or at significant additional expense; granularity of delegation is limited and its primitives expensive, leading to programmer error and extremely limited use of granular separation. Poor programmability contributes directly to poor security properties.
That is not what I see in the 1967 MMU for the IBM 360 model 67 (Blaauw box).
I see a C-list in the segment table and another in each page table.
The conveniently sharable memory portions come in only a few sizes but the waste is mostly virtual and not real memory.
I see no reason to claim that mutual trust was assumed.
Page 15:
Unlike past research into capability systems, CHERI allows traditional address-space separation, implemented using a memory management unit (MMU), to coexist with granular decomposition of software within each address space.
This is a clear and useful statement to which I give the Keykos counterpart.
Keykos uses the MMU to separate mutually suspicious system elements.
Keykos encourages type safe languages to process data from untrusted sources.
Keykos has not moved far on the 2nd thrust.
I am waiting to see synergy between these two thrusts.
I agree that they reinforce each other.
Page 29: The authors describe machines that lacked a STO STACK which was a hardware that allowed several address spaces to be loaded at once in the TLB.
Search for “STO stack” in this.
The TLB was not flushed upon space switch.
-------
Page 30.