[cap-talk] [CapROS-devel] Rescind vs. sever

[David Hopwood]

[I've added cap-talk, and set 'Reply-To' there, since 'Sever' is an
interesting primitive in contexts other than CapROS/KeyKOS.]

I wrote:
> Charles Landau wrote:
>> In KeyKOS, there were two operations that rescinded keys.
>>
>> "Destroy" rescinded all the keys and freed the object. When the 
>> object was next allocated, it would be cleared.
>>
>> "Sever" rescinded all the keys, returned a new key, and did not 
>> change the object's state.
>>
>> Were there compelling uses of the Sever operation? If it were 
>> eliminated, two kernel calls (rescind keys, and clear the object) 
>> could be combined into one.
> 
> It seems that 'Sever' can be simulated by calling a 'clone' method
> on the object, and 'Destroy'ing the original object.
> 
> The differences between the simulation and the original design are
> that:
>  - not all objects necessarily provide a 'clone' method, or any
>    other way to copy out the object's state. (The lack of such a
>    method might be intentional.)
>  - the 'clone' method of any given object might not actually perform
>    a (shallow) copy.

... and might not return promptly (or at all), in which case the
original object would not be destroyed promptly (or at all). So
perhaps this is not such a good simulation.

>  - calling 'clone' and then destroying the original object is not
>    atomic; two copies of the object exist before the original is
>    destroyed.
> 
> I don't know KeyKOS well enough to say whether there were compelling
> uses in that context; in general 'Sever' doesn't seem all that useful
> (no object language that I know of has a similar operation, although
> most have a convention of providing 'clone' for almost all objects).

I'm also dubious as to whether we want 'Sever' to work on all objects,
rather than only objects that agree to it. Performing a 'Sever' on
an object that is relying on receiving callbacks, would result in
an object that is broken in ways that might easily be overlooked in
a security review.

'Sever' is definitely an additional primitive not included in the
object capability model, and on general principles I think we'd like
to minimize such primitives in capability system designs.

-- 
David Hopwood