[cap-talk] Modelling capability manipulation

[Charles Landau]

Neal H. Walfield wrote:
> I've gotten the (perhaps incorrect) impression that an
> object-capability system ought to implement exactly one system
> call---ipc / object invocation---and that all other functionality
> ought to be made available by way of this primitive.

I don't agree that this is necessary. Other system calls could be 
allowed, provided it is clear that they don't expose any authority that 
you might want to control.

For example, in CapROS for the ARMv5, there is a system call that does 
an atomic compare-and-swap of a word in memory, because the ARMv5 
architects were not kind enough to provide this in hardware. ARMv6 does 
have an instruction that can be used for this.

> What then is the right way to think about capability copy?  

In KeyKOS capability copy was implemented as Bill Frantz described and 
not as an unrestricted system call, only because we wanted a way to 
implement virtual machines. For that, all system calls had to be 
interceptable. The way to do that, without adding any checks in the 
high-performance path, was to have only one system call (invoke 
capability) and give the process only capabilities that could be trapped.

CapROS does have a system call that will copy a capability from one 
capability register of a process to another.

> The "natural" syntax is:
> 
>   cap_copy (target_slot, source_capability)
> 
> However, what object is being invoked?  We are not invoking the object
> designated by target_slot.  Indeed, target_slot may not even contain a
> capability that designates an object.  Rather, we are invoking the
> object that contains the slot target_slot with source_capability and
> the residual symbolic address after looking up that object.  That is,
> a more accurate interface would be:
> 
>   cap_copy (object, source_capability, index)
> 
> On Viengoos, for a programmer to identify the object that contains
> source_capability

Do you mean target_slot?

> , he must essentially walk the address space.  

The address space (containing the target_slot) is an object that should 
be capable of doing the walk itself, just as I can store into a data 
word without explicitly doing a walk.