[cap-talk] Modelling capability manipulation

[Jed Donnelley]

At 04:28 PM 11/20/2008, Charles Landau wrote:
>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.

I agree.  To me what constitutes a "system call" vs. any other
instruction seems rather arbitrary - except when it comes to object
invocations - where the issue of the "insertion property"
(ability to simulate, virtualize, "membrane") comes into play.

>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.

A capability copy seems to me to fall into the same category.

> > 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.

Hmmm.  I think perhaps getting into detail with the particular concept
of "virtual" might be a bit beyond the scope of the question.  I guess
you (Charlie, Bill, KeyKOS, etc.) weren't trying to virtualize hardware
instructions (e.g. a typical VM concept like VMWare, VM370 and the like).
It seems to me that what the object/cap model requires is that each object
be able to be simulated with another.

>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)

Hmmm.  Isn't this essentially A = B?

> > 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.

I have no problem with local capability "variables" (e.g. "registers")
and so this effort at forcing an invocation seems to me unnecessary.

> > That is, a more accurate interface would be:
> >
> >   cap_copy (object, source_capability, index)

The above seems to me something different than A = B.  If somebody
can suggest what an A = B primitive makes impossible to simulate
("insert") then I think we could address this question in that
context.  I don't believe there is anything, but if there is
then it seems to me we could use such an example to refine what
is needed for the capability copy.

> > 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.

I'm afraid you lost me with the notion of the address space walk.
Are you referring to the act of "map"ping data from an object
into memory?  To provide the insertion property (I hope I'm using
a term sufficiently accurate) for this case it must be possible
for the object to handle any memory reference.  While there can
be complexities to such an implementation, I believe they are
independent of the "copy" notion, unless of course the source
or sink of such a copy is in an object.  I don't see a problem
with distinguishing these cases.

--Jed  http://www.webstart.com/jed-signature.html