Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Sun, 2006-04-23 at 00:31 +0200, Bas Wijnen wrote:
> On Sat, Apr 22, 2006 at 02:07:00PM -0400, Jonathan S. Shapiro wrote:
> > > > > I think the following condition should be sufficient: The kernel
> > > > > guarantees that a reply message is sent _at the latest_ when the
> > > > > callee process is destroyed.  This should hold true independent of
> > > > > what the callee does between being invoked and exiting.  In
> > > > > particular, simply dropping the reply capability should not change
> > > > > this guarantee (which in effect means that the kernel has to invoke
> > > > > the reply capability when it is dropped).
> > > > 
> > > > Several problems:
> > > > 
> > > > 1. This requires dynamic storage allocation in the kernel. Dynamic
> > > > storage allocation in the kernel implies denial of resource
> > > > vulnerabilities and makes any statement of kernel robustness impossible.
> > > 
> > > Can you elaborate why you think that dynamic storage allocation is
> > > required?
> > 
> > You stated that "simply dropping the capability [does not remove the
> > obligation]". In order to satisfy this requirement, the kernel must keep
> > track of every reply capability that a service ever receives.
> 
> 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.

> > It can shrink the list when it notices that some of these capabilities have
> > become invalid, but in abstract this could require an arbitrarily large
> > amount of storage.
> 
> No, at most one notification slot per capability.

Yes, but an arbitrary pool of clients can send an infinite number of
capabilities!