Re: Reliability of RPC services

[Bas Wijnen]

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?

> > > 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!

Yes, my remark didn't make much sense.  Sorry about that. :-)  What I wanted
to say was that not only is this arbitrarily large amount of storage no
problem for the kernel (because I assumed it would be part of the capability
structure), but it would also not be a problem for the applications, because
they reserve space for a number of capabilities, and the storage doesn't get
bigger than that.  So even though it is an abitrarily large amount, no party
will be unpleasantly surprised by the bill. ;-)

Of course this is completely irrelevant if the capability storage mechanism
isn't as I expected it to be.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature