[EROS-Arch] Questioning need for Call Count

Bill Frantz frantz@communities.com
Thu, 09 Nov 2000 13:10:18 -0800


GAK!  This proposal means if I don't fully trust the implementation of, and
the people who hold/can obtain domain keys to, every domain I call, then I
have to check the serial after every call I issue.  It also eliminates a
common pattern in KeyKOS of using the resume key to resolve races.  (Two
domains hold it, the first to use wins the race.)  It seems an invitation
to obscure buggy code.

At 01:47 PM 11/9/00 -0500, Jonathan S. Shapiro wrote:
>The current EROS (and KeyKOS) resume capability is "consume on use" to
>ensure that each call receives at most one reply. The implementation of
>this is somewhat ugly, and I am coming to question whether it is really
>necessary.
>
>The resume capability itself remains necessary. We need a mechanism to
>distinguish between replying to a call and sending a new request, which
>is what the resume capability provides. [In one case the client is at
>top of stack in the receive() part of its event loop, in the other it is
>deep in the stack and not expecting a brand new request.] I'm
>questioning whether the call count is necessary.
>
>An alternative would be to build room for a call count into the data
>exchange protocol but not implement call counts within the kernel
>mechanism. Clients concerned about repeated replies can simply increment
>a 64-bit counter and pass the value along with the payload. Servers
>would then be written to reply with the same sequence number. The client
>is free to check this sequence number or not, as it pleases. The resume
>capability would no longer be consumed when it is used, though in the
>usual case I would expect it to be overwritten quickly.
>
>Under this design, a malicious server becomes able to screw with a
>client after it replies to that client by playing games with the
>sequence numbers and continuing to reply. Frankly, a malicious server is
>able to mess with the client in so many other ways that I don't really
>see this as a compelling problem.
>
>Unless I'm missing something important (which I certainly might be), the
>resume capability consumption is not a security mechanism. It's a
>mechanism designed to catch a certain class of programming errors. A
>user-level counter catches them nearly as well, and involves a much
>simpler and more regular invocation protocol.
>
>
>Reactions and Opinions?
>
>
>Jonathan
>_______________________________________________
>eros-arch mailing list
>eros-arch@mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/eros-arch
>
>