[cap-talk] keyrings and bootstrapping capabilities

Norman Hardy norm at cap-lore.com
Mon May 28 23:23:18 EDT 2007


On 2007 May 28, at 4:37 PM, Jed Donnelley wrote:

> At 12:40 PM 5/28/2007, Norman Hardy wrote:
>> Thanks Jed for the additional background.
>>
>> On 2007 May 28, at 12:25 AM, Jed Donnelley wrote:
>> ........
>>> If, however, one is given access to a directory without
>>> the "free access" right, then all access rights that are
>>> turned off in the directory capability itself are turned
>>> off in the fetched capabilities before being returned
>>> in response to "fetch" requests.
>>>
>> Of what use is such a returned capability?
>> Perhaps rights amplification was necessary to use it.
>> Keykos did not use this pattern but the kernel could support it.
>>
>> ......

......
>
> Remember the idea?  I'm sure we've discussed it on the cap-talk
> list before.  I believe I've seen this ideal elsewhere, but not
> before it was done in the Elephant storage system circa 1970.
> This seems to be another one of those ideas that has been
> invented more than once.

Yes, This pattern occurs in Keykos when a sensory key to a node is  
invoked to fetch a capability therein.
The kernel understands nodes for it responds to invocations thereof.
It understands pages and that RW page keys can change the page.
If there is a RW page key in the node and the holder of the sensory  
key does a fetch for that key, then the RO key to the same page is  
returned.
If node A holds a node key to node B and X fetches that key by  
invoking a sensory key to A, The X gets back a sensory key to node B.
Thus the kernel supports perusing a tree of nodes starting with a  
sensory key to the top node.
These actions cannot lead to modification of anything in the tree.

There was no such kernel facility for the directory because the  
kernel was not directory savvy.
The directory was an ordinary object implemented in user code,  
outside the ken of the kernel.
I don't remember but we could have easily provided a wrapper for a  
directory that would yield only like wrapped access to directories  
therein, and RO access to pages and segments therein.
With such wrappers the sensory assurance would depend on code outside  
the kernel.
At this level of objects there are many other concepts of mutability  
to contend with; the page, segment and directory each have their own.
Some capability systems have a bit presumably devoted to RO and its  
generalization within each capability.
We could not find a semantics for this bit in the case of a start key.
Here is a failed attempt: http://cap-lore.com/CapTheory/Confine/ 
sensoryGate.html
The kernel is not in a position to ensure that an invocation of user  
code (via a sensory start key) will leave the invoked object unchanged.
If we had made the directory into a kernel object, even an honorary  
kernel object, then we could have provided a sensory kernel key.
That seems jarring!


More information about the cap-talk mailing list