[cap-talk] EQ, MyCap? review

[Jonathan S. Shapiro]

On Tue, 2008-02-12 at 15:29 -0800, Jed Donnelley wrote:
> On 2/12/2008 2:20 PM, Charles Landau wrote:
> > The object that implements the Amplify Gate Key method is the Process 
> > Creator, but this may change in the future.
> > 
> > In EROS/CapROS, the capability to a caller that allows the callee to 
> > reply is called a "resume" capability; in KeyKOS it's an "exit" key. 
> > Amplify Gate Key and Identify_Exit recognize these capabilities too.
> > 
> > I hope this helps with the terminology. Amplify Gate Key is very 
> > equivalent to MyCap?, for reasonable definitions of "My".
> 
> I think I'm understanding.  Is there a one-to-one correspondence
> between start/entry capabilities/keys and service processes?

In EROS/KeyKOS/CapROS: no. Each "start" capability has a 16 bit field
called the "key info" field that is delivered to the recipient when that
start key is invoked. This allows a single service to implement multiple
interfaces. Note that the invoker cannot alter the value delivered, so
this value is a form of "protected payload". Separately, in EROS,
KeyKOS, and CapROS invocation may be indirected through a suitably
constructed Node.

In Coyotos: no. Entry capabilities name an Endpoint object and contain a
32-bit protected payload field that replaces key info. The Endpoint
object in turn contains a Process capability to the process that will be
invoked. Note that because of the indirection, any party holding an
Endpoint capability to that Endpoint can redirect future invocations to
a new destination. Typically, the only holder of the Endpoint capability
is the recipient.

> Assuming so, then I guess the "brand" mechanism is a means to
> support multiple distinct start/entry capabilities/keys within
> a common "domain" by allowing a process entering the "domain"
> via one start/entry capability/key to access the internal
> state of a start/entry capability/key that might have been
> passed in as a parameter?  In that sense to get access to the
> "private" data for the object?

Not so. The protected payload (which is the only part of the start/entry
capability that might be usefully inspected) is provided to the
recipient as an OUT parameter of the invoke capability system call. No
brand manipulation is needed to fetch it.

In KeyKOS/EROS, the brand was mainly used for process teardown, allowing
a start/resume cap to be "upgraded" to the corresponding process cap. I
do not know if this is still true in CapROS. The brand is also used to
authenticate the program you are invoking.

In Coyotos, this use of the brand has largely disappeared, because
processes are now allocated from space banks. The remaining uses of the
brand value are for authenticating the program you are invoking. Coyotos
also introduced a variant IsPeer operation, which allows a process to
identify (and avoid invoking) entry capabilities to itself or (in a
variant invocation) one of its "peer" threads in a multithreaded
applicatoin. There are various fun deadlocks you can get into if that
operation is missing.

> If all the above guesses are correct, then the definition of "My"
> is essentially 'serviced by a process within the same brand'?

No.

If you like, you can see the specification of the relevant Coyotos
operations here:

  http://www.coyotos.org/docs/ukernel/spec.html#coyotos.Process

See in particular the identifyEntryWithBrand, identifyEntry, and
amplifyCohortEntry.

The identifyEntryWithBrand operation is used by the constructor to
identify processes that it has created. This is the underlying primitive
for authenticating programs.  The identifyEntry operation reveals
whether the entry cap names some process that has the same brand as the
invoked process cap (and therefore presumably executes the same
program). The identifyCohort operation is allows a Process to identify
other Processes that are acting as co-equal threads in a multithreaded
application.


Not sure if this clarifies or obscures.


shap