[cap-talk] Delegating Responsibility in Digital Systems: Horton's "Who Done It?"

[Mark S. Miller]

Charles Landau wrote:
> In Figure 1, there are two rectangles labeled "Bob". Are these two 
> different objects? If not, did you make separate boxes just to avoid 
> a tangle of arrows? It's a little confusing either way.

Clarifying text added:

"All such rectangles with the same label are references to the same Who object."

Thanks.


> makeproxy does not seem to use its first parameter.

The first parameter is now gone from the code and the diagrams. Thanks.


> What if B happens to have a getGuts method and A says b.getGuts()? It 
> appears that P1 won't forward that. I can see how to fix this, but 
> your simplified code doesn't do it.
> 
> At line 03, P1 calls an arbitrary capability passed by A. It might be 
> wise for P1 to use a primitive such as MyCap? to ensure it is talking 
> to another proxy.

Weasel words added:

"P1 asks for the value of P2’s stub and whoBlame fields, which hold S2 and 
Carol’s Who (03–05). (To protect against misbehaving app-objects, P1 actually 
does this by rights amplification[11] rather than the getGuts message shown 
here.)"

Thanks.


> It isn't clear what the purpose of the "t" in p3Desc is.

It's gone.


> There's a fair amount of calling between the mutually suspicious 
> Alice, Bob, and Carol. As previously discussed (around 
> http://www.eros-os.org/pipermail/cap-talk/2006-December/006278.html), 
> there's no guarantee that these calls will return soon, if ever. For 
> example, Carol has the ability to delay forever the message from A to 
> B. In the absence of Horton, Carol is limited to delaying anyone who 
> *invokes* C, but not anyone who merely *passes* C around. I doubt 
> there's any way around this without something mutually trusted. In 
> some concurrency models (KeyKOS/EROS/CapROS), the lack of a guarantee 
> of a return will be a problem.

I chose not to try to say anything about this in the submitted paper. But to 
address the points here, I have posted the following two variations of the 
Horton code in the paper:

<http://www.erights.org/elib/capability/horton/base.html>, which is the 
sequential code from the paper augmented only with logging, so we can see who 
can log what.

<http://www.erights.org/elib/capability/horton/eventual.html> is the above 
code modified so that all inter-principal interactions use only 
eventual-sends, promises, and when expressions. This should enable these 
principals to be run in separate vats. I claim this transformation avoid 
introducing any liveness hazards beyond those present in a non-Horton mediated 
interaction between A, B, and C. In particular, should Carol's S2 be 
unresponsive, the argument B receives will be a promise that never resolves. 
Resource considerations aside, this hazard is no worse than Carol's C being 
unresponsive to messages from Bob.

Other differences between this Horton-mediated interaction and the 
non-mediated interaction:

* The Horton-mediated interaction is constrained to proceed in E-Order even if 
the base object-capability system only guarantees FIFO order. This isn't an 
issue for E of course, but is for Horton on ref_send, since ref_send only 
guarantees FIFO.

* The Horton-mediated interaction cannot pipeline requests even if the base 
system does, since Horton needs to resolve who to blame before letting a 
message get sent.

* In the unresponsive S2 case explained above, the undelivered messages sent 
by B will be occupy memory in Bob's vat. In the base non-mediated system, 
where the storage obligation falls depends on what's unresponsive. If Carol's 
vat's remoting system is unresponsive, then Bob's vat is still burdened.


> "messages in flight" - cute, but "messages in transit" is more accurate.

fixed.


> skyhunter.com/marcs/SecurityPictureBook.ppt - would you please make 
> this available in a non-proprietary format?

The link to the non-proprietary pdf is now in the paper.

The paper as submitted is at <http://www.erights.org/download/horton/document.pdf>

Thanks again!

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM