Re: Reliability of RPC services

[Michal Suchanek]

On 4/24/06, Jonathan S. Shapiro <address@hidden> wrote:
> On Mon, 2006-04-24 at 11:09 +0200, Bas Wijnen wrote:
> > On Mon, Apr 24, 2006 at 12:24:34AM -0400, Jonathan S. Shapiro wrote:
> > > On Sun, 2006-04-23 at 00:31 +0200, Bas Wijnen wrote:
> > > > This can be done in the capability structure itself, which is paid for 
> > > > by
> > > > the owner, not by the object or the kernel.
> > >
> > > I do not believe so. Anything that is stored in the capability itself is
> > > smashed when the capability is overwritten. I thought that Marcus wanted
> > > notification even in that case.
> >
> > I must have misunderstood how capabilities are stored.  I thought they were 
> > in
> > kernel-controlled (but user owned) memory, and could only be modified via
> > kernel calls.  How else can you protect against forging them?
> >
> > So I was assuming that the kernel needed to do the overwrite on behalf of 
> > the
> > program.  In that case it can include the notification check as part of that
> > operation.
> >
> > But appearantly I misunderstood how things work.  Could you please explain
> > this a bit?
>
> Let us start closer to the beginning.
>
> 1. Capabilities are only overwritten as a consequence of invoking some
> capability. Every capability invocation has input and output arguments.
> All capability writes happen as a side effect of delivering output
> arguments. That is: in a capability system, IPC is a special case of
> capability invocation.
>
> 2. All notifications are delivered by IPC. This includes death
> notifications.
>
> These two statements together lead to a reductio problem: every IPC may
> be required to send other IPCs before it can proceed. The reductio can
> be solved provided that the death notification does NOT transfer any
> capabilities (which, fortunately, it does not).
>
> However, we now have the situation that if the initial invocation sends
> K capabilities, there may need to be as many as K death notices -- one
> for each overwrite. In Coyotos, K may be as high as 256. Sending K
> notices is certainly not the usual case, but it must be a case that
> works well if the system architecture is to be clean.
>
> It is difficult to imagine how to make things slower than Mach, but this
> approach would definitely do the job.

It is the job of the server to manage its capabilities so that no such
notices have to be sent. Ideally, the server will either drop the
capabilities intentionally one by one (when it decides it will not use
them) or use them to return results.
The case when many capabilities are overwriten with a single IPC is
most likely a bug in the server. In that case it is much better to
inform the clients whose capabilities have been overwritten. This may
raise a question who pays the CPU cycles needed for all the
notificatications. But I still think it is better if a system is
slowed down in case of malfunction instead of  locking up.
>
>
>
> In any case, it does not achieve the desired objective. What this design
> provides is "notify on capability overwrite", which is MUCH too strong.
> It provides the recipient with very fine grain information about
> capability drops (which should not be disclosed).

In the standard case the capability should be used to return a result
to C. Why is it a problem if C receives an error when that capability
is dropped instead of waiting indefinitely? It is just another sort of
result. Instead of confirming that the service was performed it
informs C that the service has failed for some reason.
If S does not want C to know that it has dropped C's capability it
should be able to reject send-once capabilities from C. Or all
capabalities from C for that matter.

>
> Also, remember that these capabilities must be "invoke only once", so
> any overwrite of any of these capabilities will send a death notice, and
> that death notice will guarantee that the client will never get a reply
> from any other copy.
>
> So in Marcus's scenario where C calls S which delegates to T, note that
> S must not overwrite its capability until T replies. This essentially
> defeats the purpose of delegation.
>

I do not understand this. If it is a send-once capability, and S
delegates it to T, how can S overwrite it? Since it has delegeted
(moved) it to T it no longer possesses any copies that can be
overwritten.
If S chooses to mediate the communication between T and C, it does not
give the capability to T in the first place, and has to keep it until
T replies. But it is the design chioce in S to do so.
If S does not delegate the capability to T nor does keep the
capability to forward T's reply what would be the reason for C to
generate such capability and send it to S? It could just send a
message to S telling it to ping T and believe it will do so.

Thanks

Michal