Client v/s Server Resources

[Bryan Ford]

Well, I'm finally back; I see the discussion hasn't been
slacking off... :-)

>I finally sorted out what Bryan was talking about in referring to
>client-provided resources.  What tipped my off was the idea of
>client-supplied stack.
>
>There's a security problem there.  One would like to be able to
>implement services that provably cannot muck with their client's state
>except as provided for in the interface specification.  For both
>correctness and security one wants the scope of the interface to be
>contained.

No, there's no security hole - by "client-supplied stack" I mean,
in KeyKOS terms, the client supplies a space bank key from which the
server allocates a stack on which to service the client's requests.
The client is "charged" for the memory allocation, but does not
actually have direct access to the memory.  The server only needs
to trust the space bank (it can reject keys to space banks it doesn't
trust); it doesn't need to trust the client.

So, getting back to my original point, if _all_ server resources
used on behalf of a client are "charged" properly to that client,
then there's really no problem with the client using up arbitrary
"server" resources (such as leaving threads hanging in the server).
Since those resources really "belong" to the client, the client is
only wasting its own resources.

As has been pointed out, KeyKOS already supports this for the most part;
just wanted to clear up the misunderstanding.

				Bryan