l4-hurd
[Top][All Lists]
Advanced

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

Re: Design principles and ethics (was Re: Execute without read (was [...


From: Marcus Brinkmann
Subject: Re: Design principles and ethics (was Re: Execute without read (was [...]))
Date: Sun, 30 Apr 2006 17:15:21 +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 Sat, 29 Apr 2006 22:23:16 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> > That too, but that's not the reason it's confinement.  It's confinement
> > because the child process cannot communicate with anyone, except with 
> > explicit
> > permission of the parent (in the form of a capability transfer).
> 
> It is also not confinement if the parent can read the child without the
> consent of the child. Therefore it is not confinement at all.

The child *does* give the consent because the parent *instilled* into
the child the consent in the first place.

The mistake you are making is that you use a definition of "external"
(see my other mail) which is too narrow.  You are only considering the
case where the parent (or instantiator) is different from the creator
of the program.

However, this is NOT the only possible configuration.  There is also
the case where the instantiator is identical to the creator, and in
this case, the program is still confined.  If this were not the case,
your definition of confinement would make no sense.

So, your definition of confinement _includes_ the case which I call
"trivial confinement".  Again, to make it perfectly clear, in EROS
terminology:

With these definitions:

creator := the creator of the confined constructor object
instantiator := the user of the confined constructor object

Then:

Trivial confinement     <=>  (creator == instantiator)
non-trivial confinement <=>  (creator != instantiator)

I know that you are very, very, very interested in "non-trvial
confinement".  I know that I am proposing that "non-trivial
confinement" should not be supported, and that this precludes use
cases you are interested in.  All this has been discussed at length,
and will surely continued to be discussed.  However, we must make sure
that we use a common language, and that we agree on the laws of
grammar and logic, before we proceed.

If you still disagree, please provide a complete argument.  A
definition of confinement that contains undefined terms like
"external" is not sufficient.

My suspicion is that you do not actually disagree with the above
facts, but that you consider trivial confinement to be totally
irrelevant, while all your money is on non-trivial confinement.  Tough
luck, because it is the opposite for me.  So, I have to insist that
trivial confinement is indeed confined, because it is relevant to my
argument.

Thanks,
Marcus





reply via email to

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