[Top][All Lists]

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

Re: Part 2: System Structure

From: Bas Wijnen
Subject: Re: Part 2: System Structure
Date: Wed, 24 May 2006 09:22:00 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Tue, May 23, 2006 at 04:32:01PM -0400, Jonathan S. Shapiro wrote:
> > > This capability also allows checking that these banks are opaque.
> > 
> > In all your scenario, you seem to omit something: without the
> > constructor mechanism, no process can verify anything accurately about
> > any other process, except if all of the parents of it are to be trusted.
> Yes, in two senses:
> 1. Parents must not be able tamper with the constructor, therefore it
> must not be writable even if executing on parent storage.

The constructor itself is not running on the requestor's storage.  This is
true in your model, and also in mine (where I don't call it a constructor, but
more generally a "service" which can start a process on request).

So that is no problem either way.

> 2. The constructor authentication mechanism relies on the existence of
> an exclusively held and unrevealed capability (the brand). This
> capability must not even be *read* by parents.

Yes.  This is not only true here.  In the ping case, I expect we need to
provide read-only memory to the process.  However, the capabilities it holds
must of course not be readable.

> I think Marcus has stated that he has an alternative way to do this. I
> do not understand how his method works.

It is based on a check for a server to see if a capability is for an object it
implements itself.  This should be a kernel provided operation on any
capability.  I suppose it's pretty trivial to implement, but please let me
know if you see any problems with it.

> > That is, except for a process spawned by the TCB, no capability can be
> > trusted not to be faked or sniffed. And AFAIK, there is no mean for a
> > process to check that it has been spawned by the TCB.
> > 
> > But when a process is spawned by a constructor and given some
> > capabilities to the TCB that the requestor cannot spy or alter, it is be
> > given the ability to check properties of it's environment accurately.
> Yes. The constructor can be substituted, but only if the metaconstructor
> and the prime space bank and the installer are also substituted.

Just to be clear: You are not talking about replacing the constructor
mechanism with something else (as I proposed earlier, and am not sure about
now), but about replacing a specific constructor in your system with an
untrusted one.  For that, you need to substitute the meta-constructor as well
(and the "problem" is that the server you're calling doesn't accept your new

This is in fact very similar to how things are in my system, where it's all
about space banks (and process hierarchies are quite irrelevant): In order to
trust something, it must be referring to the same session manager that the
server has a capability to (and that session manager is supposed to hold the
primary space bank).


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

Attachment: signature.asc
Description: Digital signature

reply via email to

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