[cap-talk] Why is EQ so dang fascinating?

[Jed Donnelley]

On 11/6/2007 9:47 AM, David Hopwood wrote:
> Jed Donnelley wrote:
>> At 01:08 PM 11/5/2007, Charles Landau wrote:
>>> At 11:34 AM -0800 11/5/07, Jed Donnelley wrote:
>>>> On 11/5/2007 11:09 AM, Charles Landau wrote:
>>>> ...
>>>>>  With EQ, the bank wouldn't need to invoke a malicious purse, and I
>>>>>  would always know any slow response would be the fault of the bank.
>>>> Doesn't MyCap suffice for the above?  That is, isn't the purse
>>>> a capability supported by the bank?  If you are going to try to
>>>> arrange to be able to only blame the bank (or whatever single
>>>> service), then it seems that all related capability invocations
>>>> must be internal to that one service - hence subject to MyCap
>>>> rather than the more general EQ.  Right?
>>> Right.
>>>
>>> At 11:09 AM -0800 11/5/07, Charles Landau wrote:
>>>> I'm curious how you would design a robust protocol in the above
>>>> example, without using timeout or EQ.
>>> Still curious, without timeout or EQ or MyCap.
>> Curiosity understandable.  Curiosity notwithstanding, I just want
>> to make sure everybody knows that unlike EQ, the MyCap operation
>> is an invocation on a capability (the type extension capability),
>> and is thus subject to simulation, wrapping, etc.  MyCap is
>> thus less "fascinating" (problematic) - though seemingly it's
>> base implementation still needs to look at the innards of a
>> capability.
> 
> I tried to simulate MyCap in terms of pure FIFO message passing
> (without timeouts), and *nearly* got there. The obstacle I ran into
> is that to prevent an attacker who also has access to the cap being
> tested from interfering with the protocol, you would like to use a
> token that is specific to that protocol run, but the check that
> something is a "real" token seems to need something equivalent to
> MyCap.
> 
> MyCap can definitely be simulated in terms of 'IsAToken' and
> pure FIFO message passing, where 'IsAToken' is a prompt test
> of whether a given cap is a primitive token. IOW, if you can
> do MyCap for one kernel type then you can do it for any type.
> 
> I'll keep thinking about it for a bit longer, and report my
> conclusions then.

David,

Thanks for your message.  I wasn't sure whether or how to
respond and I'm afraid I'm still not, but I thought it might
be worthwhile trying to clarify some aspects of how I
understand "MyCap?" to see if we are thinking along the same
lines.

Any capability system that supports extension (any
worth its salt in my opinion) needs a means for
an executing program to make up a new capability
that it can service.  That is, a new capability which,
if invoked, will result in a message that can be
received by the program making up the new capability.

Programs can make up such new capabilities and then:

1.  Send them out into the world, and
2.  Service requests on them.

Having done so, sometimes it is useful to be able to
determine if a capability received by such a servicing
program to be able to determine if a capability that
it received is one of it's own - and if so which one
of it's own.  The first time I ran into this was in the
design of the DCCS:

http://www.webstart.com/jed/papers/DCCS/

Any membrane mechanism will likely need such
a facility.  You can see this when the membrane
mechanism receives a capability through
an invocation through its membrane and
wonders how to pass it on to the underlying
"real" object.  If the parameter is one of
it's own it may wish to pass "down" the
corresponding "real" object vs. passing
directly through the simulated object of
it's own.

Regardless of the application, for me the
idea of the "MyCap?" call is that the program
invokes a "master" capability (some capability
that allowed the creation of simulated
capabilities to be serviced to begin with)
and can pass in a capability as a parameter
(possibly many - an efficiency issue) and
can ask "MyCap?".  The result is either
"No" or "Yes" and if "Yes" some designation
as to which one.


In the above I'm just stating my understanding
for the record to see if we are thinking
along the same lines or not.

Whether yes or no, at that point I'm afraid
I don't understand what you mean when you
try "to simulate MyCap in terms of pure FIFO
message passing (without timeouts)..."

Could you explain more what you mean by the
above and give me a check on whether we
mean the same thing or not by "MyCap?"

You say that "IsAToken" is a prompt test
of whether a capability is a primitive
token (capability?).  I can understand this
concept for many capability systems (e.g.
the KeyKOS line) - though it's unclear to
me what capability would be invoked with
such a call.  The capability to be tested
itself or some other "supervisor" capability
or perhaps no capability (as with EQ?)?

When you argue that "MyCap?" can be simulated
in terms of 'IsAToken' and pure FIFO message
passing, I don't understand how that would
work.  Even if "IsAToken" can determine whether
a capability is a primitive type or not, how
can a simulation of "MyCap?" determine whether
a given capability is serviced by a particular
object and which capability it is that points to
that object?

I'm just trying to clarify my understanding
here, so your indulgence (perhaps pointers?)
is appreciated.

Thanks.

--Jed