In Keykos, how do I pass a memory segment to you so that you can process the data in that segment knowing that I, who stored into it to create its value, no longer have the authority to continue modifying it? Here is how:

I choose a power of 16 sufficient to hold the data. I choose a multiple of that power as an address for a segment of that size. I call (thru a gate) a service US that sells ‘uniquable’ segments and get by return a capability to a new segment, virtually zero initially. I place that capability in a node of my memory tree so that the new segment appears at the chosen address. I store into the segment until I have produced the value I want to send you. I send you the capability to the segment.

You suspiciously send that capability to US (the one and the same) with the query, “Did you make this? And if so return to me a new segment with the same data.”. This is the “Renew” order on the US service. If I did as I claim above US is in a position to recognize the segment that it produced and perform a kernel ‘renew’ operation on the top node that severs all capabilities to that node and creates a new unique capability to that node which it returns to you. You and I both trust US to work as advertised and thus you know that any capability to the segment that I might have held has vanished. You place your new capability in a node that causes the newly christened segment to appear at an address that you have chosen, knowing that you have unique access to that segment.

The renew kernel call caused my memory map to instantly loose access to pages of the segment and even the page table that holds the real addresses of those pages. The TLB will be purged so that this denial is immediate. The data in the segment remains where it was in RAM and eve cache. If I should accidentally store into the segment after I have sent you the capability then your snapshot will show that modification, but if I store into the segment after your renew call to US I will get a memory trap. Your segment will be unmodified by me subsequent your renewal call to US.

This technique supports these ideas.

Storage Accountability

In the Keykos context there is a problem with analogs with other contexts: Who owns the transferred storage in the sense of being responsible for reclaiming it when no longer needed. In Keykos real storage is acquired via a space bank and the agent whose initiative created the segment is ultimately responsible for selling it back when unneeded. The transfer of sole segment authority described above is limited by the original segment creator’s remaining authority to delete the segment by so directing the bank on which segment relies. A bank feature that was not implemented in Keykos but which was not especially difficult, was to register the pages and nodes of the transferred segment with a new bank that you provide in the renewal invocation. The basic problem here is the time to do so. The renew call on US to adopt a segment might optionally include a bank reference to which the material in the segment is to be transferred. An alternative might be that the creator trust down-stream segment users to delete the segment. The creator is in a position to limit the warrantee to 24 hours, say; the new segment will expire after some stated period. The creator still lacks authority to change the segment but maintains the power to delete it. This provides the reader of the segment with an easily recognized signal of a segment fault if the reader reads a segment that he has not adopted by accepting the cost of keeping it.

Another design possibility is for US to take on another responsibility: accept a bank key upon renewal and perform a renewal at some later time the I specified if you have forgotten to delete the segment.