l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services


From: Marcus Brinkmann
Subject: Re: Reliability of RPC services
Date: Mon, 24 Apr 2006 11:16:00 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 24 Apr 2006 00:24:34 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> 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.

I am not sure where the communication problem is.  Bas described the
send-once notification proposal like this (I tuned it a bit to make it
clearer):

- A capability can be given a "send-once" flag on creation.
- When this capability is copied, the source capability is invalidated.
- When the capability is used, it is invalidated.
- When any capability is destroyed or overwritten, AND it has the send-once
  flag set, AND it is still valid, a death notification will be attempted.

Invalidating a capability means to change its type to a void
capability, for example.

So, obviously, in the capability overwrite case, the kernel has to
attempt to send the death notification before overwriting it.

Thanks,
Marcus






reply via email to

[Prev in Thread] Current Thread [Next in Thread]