Re: Part 2: System Structure

[Marcus Brinkmann]

At Thu, 25 May 2006 11:30:54 +0200,
"Michal Suchanek" <address@hidden> wrote:
> 
> On 5/24/06, Marcus Brinkmann <address@hidden> wrote:
> > At Wed, 24 May 2006 16:37:47 +0200,
> > "Michal Suchanek" <address@hidden> wrote:
> > > > We already have a mechanism to provide such capabilities.  It is
> > > > called a "file" capability to the binary image.  This is all I need to
> > > > support all the features I want to support.  Everything beyond that is
> > > > "in the way".
> > >
> > > If you give up the possibility to create restricted binaries the
> > > binary will not exist in the first place. It will be part of some
> > > service, and you will never see that there is a capability. And you
> > > will not be able to trace it anyway.
> >
> > Somehow the discussion managed to drift away from its starting point.
> > My response to Jonathan was about using the constructor mechanism as
> > the prime mechanism for program instantiation, that means all cases,
> > in particular those which are not the controversial, restricted ones.
> > It is those cases of program instantiation I was talking about.
> >
> 
> But in the case the binary is not restricted in any way you can give
> it the capabilities you want and trace it to your liking. I do not see
> how the constructor gets in your way in this case.

The constructor will, by default, give the program capabilities to
some system services, like the meta-constructor and space bank, so
that the instantiated program can authenticate capabilities to them.
This mechanism has to be disabled, which requires an extension to the
constructor, or you have to use the disclose functionality of the
constructor to extract the program data and then use that to
instantiate the program yourself, by creating a new constructor or by
doing it manually.

I did not say that it is impossible to do this.  This is not how I
used the words "in the way".  However, it is not the direct way of
doing it.  In implementing my system structure, the constructor serves
no purpose.  It holds all the capabilities needed for program
instantiation.  Well, in my proposal, there already is such a
capability, namely the file system (that contains the binary and all
libraries etc).

One can also see otherwise that the constructor is an extra step in
the way towards the direct program instantiation that I want to
achieve.  Whoever creates the constructor has the right to destroy it
(at least initially), and may destroy it at any time.  This is ok as
long as the constructor creator is the same agent as the provider of
the binary image.  But that means that you could have just as well
gotten the binary image instead of the constructor from the same
source.

If there is a mechanism in place that you have to disable or otherwise
work around to get what you want, then that mechanism is "in the way".
If this mechanism serves no other valid purpose (a matter of
judgement), it is not only in the way but also unnecessary.  No system
designer will include unnecessary mechanisms that stand in the way of
doing things.  Imagine the "open" system call would return the FD in a
string, and not in an integer, and you would have to parse the string
to get the FD back.  Wouldn't you agree that the "string return value"
mechanism stands in the way of getting the FD?

The problem that you and Pierre have here, which is very clear from
the arguments you are making, is not that you don't see how the
constructor is in the way (both of you described very clearly how it
is, actually, in the way), but that you firmly believe that the
constructor mechanism is necessary, and not superfluous.  This is,
presumably, because you differ on the goals and objectives.  But this
is a discussion we had extensively, and it is not what this thread was
about.  Jonathan asked me what my opinion is in using the constructor
to implement the system structure I proposed.  So, if you want to
comment constructively, you should look at it from the perspective of
my model, and the goals it tries to achieve.

Thanks,
Marcus