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! _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
