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

[David Hopwood]

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 Hopwood