I have begun to read the spec which gives a broader picture of CHERI, including compartmentalization. That was not our conclusion. They are complaining about having to pass messages between components.

Page 8:

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:

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.

Keykos shares TLB entries, memory map table such as page tables and data in cache across protection domains.

Page 13:

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:

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.