[EROS-Arch] Questioning need for Call Count

[Charles Landau]

"Jonathan S. Shapiro" wrote:

> Joerg's example prompts me to do some case analysis in the hopes that we can
> all reach agreement on what behaviors are at issue here.
>
> Under the proposed design, there are two kinds of attacks that a malicious
> service might undertake against a caller.
>
> 1. It might never return, blocking you forever.
> 2. It might return multiple times, messing up your other interactions.

Yes. And there are two corresponding types of trust when you invoke a key:
1. You trust the key not to block you too long.
2. You trust the key not to return multiple times, messing up your subsequent
interactions.

I agree that the only correct defense of (1) is to build an intermediary domain
and blow it away, in both current and proposed designs.

I think you would agree that counts checked in user mode are not an adequate
defense of (2). Counts can be forged, and even with an incorrect count, a rogue
server can cause the client to be busy temporarily, causing the client to miss
an otherwise valid return.

Trust is not all-or-nothing. One can have trust (1) without (2). (2) is a much
more insidious problem, affecting as it does all subsequent behavior of my
process.

For example: I hold a key to a server operated by my friend J. While I trust J
as a person, I consider there to be a small possibility that his code has bugs.
In the current design, I will call J's server without an intermediary. If, due
to a bug, the server doesn't return promptly, I have a couple of recourses: (a)
If the server hasn't discarded the resume key, I can call up J and ask him to
manually intervene to force the server to return. (b) I can manually invoke the
Make Process Waiting operation (see
<http://www.eros-os.org/devel/ObRef/primary/Process.html>) on my domain key to
free up my domain. In either case, the results are suspect, and I will probably
want to discard my computation. (c) I can simply manually destroy my domain and
take some alternative action. In any case, my process stopped at the point of
the call to the buggy service. Failure to use an intermediary in this case
forced me to take extraordinary action to deal with the bug in the server, but
didn't hamper my ability to diagnose the source of the bug.

Whereas in your proposal, if my process hangs up on a call, it could be due to
misbehavior of any key I have ever invoked in the history of my process. If I
want to diagnose the source of the problem, I will have to build an
intermediary on virtually every invocation. And since bugs aren't always
reproduceable, I will feel a need to build intermediaries even when I have not
yet any reason to suspect there will be a problem.

In short, I have trust (1) for J's server because I am willing to take
extraordinary action to deal with a hangup. But I don't have trust (2) for it
because it makes debugging onerous.