Re: Part 2: System Structure

[Bas Wijnen]

On Wed, May 17, 2006 at 10:49:24AM -0400, Jonathan S. Shapiro wrote:
> > > > Ok, this is a technical thing.  I'm assuming that the space bank can
> > > > provide me a page of memory which I can use.  If it's hard, I'll use a
> > > > library for it.  No problem.
> > > 
> > > It can. The difficulty is that the space bank has no idea how you glue
> > > together the pieces that it hands you. The situation is similar to
> > > having a disk driver that will give you back any block that you want.
> > > You still need to know how the file system is structured to make this
> > > useful.
> > > 
> > > Except that the process relationships are more complicated than the
> > > relationships of data structures in the file system.
> > 
> > If the constructor can do it, then a library can as well.  I don't see how
> > complexity can be an argument here.
> 
> The constructor cannot do it either. The constructor's job is to *build*
> processes. It has no ability whatsoever to do forensics based on the
> low-level object types.

Ah, you were talking about actually debugging.  Sorry, I thought you meant
that building the program was so hard.

Well, perhaps it is all much easier if the program cooperates in being
debugged.  But with a transparent space bank, it is at least possible to do it
with a program that doesn't cooperate.  If I understand you correctly, this is
not the case with a malicious program which was originally set up to be
debuggable.

> > > This has nothing to do with the open/closed/transparent issue. It's a
> > > simple matter of fault isolation. This is why I have stated my opinion
> > > that Hurd should use the Constructor pattern for process creation even
> > > if it does not impose the encapsulation and opaqueness properties.
> > 
> > While I think the problems you described may be solvable, I wasn't
> > actually thinking about shared libraries.  I was thinking about static
> > libraries.  The point is that if something requires complex code, that is
> > no reason to move it into a separate process.  It's a reason to prepare
> > the code in advance and use it when needed.  One way of "preparing" is to
> > put it in a process of its own.  A library (which can be static) is
> > another way, and it's less complex IMO.
> 
> Making this a static library is infinitely worse than making it a
> dynamic library. If you make it a static library, you can't (in
> practice) fix it.

Ehm, ok.  Now I don't understand you at all anymore.  I thought the proble of
dynamic libraries was that the code can be different when it's run than when
it was tested.  That isn't the case for static libraries.  But now the problem
is that the code is prepared at all?

> Your statement that "preparing" is sufficient is completely contrary to
> the entire history of system building experience since the beginning of
> computer science. The plain fact is that stray pointers exist, and there
> is absolutely no amount of preparation that can protect you from this
> error if you are in a single address space.

Ah, so you say the problem is that a stray pointer of the parent could mess up
the child?  Well, I see the child as part of the parent, something which the
parent wants to do, but in a protected way.  If the parent fails, the child
can be killed without any (extra) loss.  If the parent has a stray pointer,
then I'd say it's failing.  It's just as likely that it messes up itself, or
gets a segmentation fault.  And apart from that, the child's memory doesn't
have to be actually mapped into the parent's address space.  But it should be
able to map it.

> > > > Nonsense.  If a process requires opaqueness, there must be a way to
> > > > allocate opaque storage.  There's no reason at all that it must be the
> > > > default.
> > > 
> > > The problem with your approach is that it only takes one omission by a
> > > single programmer to expose a whole lot of stuff.
> > 
> > Not at all.  Consider the constructor-approach: every spawned process will
> > be a sibling of every other one.  It's a flat structure, really.
> > Therefore, using a transparent space bank in that case doesn't change
> > anything, because the parents (that's the constructors) aren't going to
> > look at the memory anyway.
> 
> We are operating from fundamentally different assumptions. I do not
> accept the assumption that a viable system can be built in which no
> child program can every guard its runtime memory image from its parent.

But with my definitions for child and parent, there really is no practical
difference.  Look at it this way: The meta-constructor does not have a parent.
Every constructor is a child of the meta-constructor.  Every other program is
the child of a constructor, and a grand-child of the meta-constructor.

If program A wants to spawn an instance of program B, it invokes a capability
to the B-constructor.  The B-constructor then builds B.  When all this has
happened, A and B are both children of their own constructor, which are
children of the meta-constructor.  In particular, B is not a child of A.  So B
has successfully guarded its runtime memory image from A (which with these
definitions isn't the parent, but I think it would be in the situation you
were envisioning).

> > > If opaqueness is the default, and you leave out the "make it visible"
> > > option, your program tends to break very quickly and you notice it.
> > 
> > Not at all.  In my use case above, it took 3 years (which obviously was an
> > arbitrary "long time").
> 
> If you really managed to go 3 years without noticing that you weren't
> transparent, then you didn't need to be transparent.

So how do you want me to debug this program?  By just looking at the code,
trying to find a place which might be corrupted over time?  That just isn't
going to work.  Agreed, with a debugger it might not work either.  But chances
are much better.

> > We can let the user provide any storage we need, except for parts which
> > must not be disclosed to them.  Obviously a buffer for an IPC transfer may
> > be disclosed to the user.
> 
> No, you cannot. Any storage supplied by the user is destroyable by the
> user, and the service must then guard itself against the possibility of
> memory faults. From a strictly pragmatic perspective this is not really
> feasible in the general case. There are a few restricted idioms where
> this is survivable, but they are *very* restricted for reasons of
> pragmatics.

And how is this different if the user would be able to give out (revocable)
opaque memory?

> > > Bas: Marcus has made it clear that he wishes me to diminish my
> > > participation, and I have a product to deliver. I simply do not have
> > > time to devote to this activity when it is unlikely that my input will
> > > produce any value.
> > 
> > I know, and I'm not happy at all with it.  But you sounded like you
> > already had several examples ready.  If that is the case, I would like you
> > to tell us.  If it costs more time, then I can understand that you don't
> > want to spend that on it.  But as I said, I'm not happy with that.
> 
> I have an enormous number of examples where private storage is
> essential. All of them have been rejected here (without, so far as I can
> tell, any semblance of serious consideration) on grounds of ideology.

I don't remember it as such, but will look back in the archives.

> Concerning the "trusted processes near the top", the most likely place
> that a problem will appear is in the problem of dynamically-sized IPC
> messages, which we are discussing above. I suggest that we put more
> attention on that for the moment.

Ok.

> That is one view. But the very fact that GPL does *not* regulate
> interactions between users (in the absence of copy) appears to have been
> an intentional decision.

It doesn't seem so to me.

> It is legitimate for the Hurd project to introduce and entire new area
> (inter-party interactions on a single machine) of "socially beneficial
> restriction" as an experiment, and to lobby that this is the right thing
> to do. However, it is important to recognize that this has HUGE
> implications, and that FSF may or may not wish to be associated with
> such a major change. At the very least, FSF input must be obtained
> before adopting a policy of this level of intrusiveness in an
> FSF-sponsored project.

I think you're making this bigger than it is.  All we propose is not to
implement something that most current systems don't have either.  I don't
think we should be forced to implement such a thing.  If the FSF wants to talk
about it, they're welcome as far as I'm concerned, but I don't see why we
should ask them specifically for input.  It's really just a detail to me.  And
one that can be changed easily at a later stage as well.

> > All you want is totally possible with a transparent space bank.  The only
> > thing is that the one who wants to keep his program secret has to pay for
> > the storage.  Ok, and encapsulation isn't guaranteed to the instantiator.
> 
> I have definitely got examples where this restriction makes certain
> secure subsystems impossible to create. Once again, the examples that I
> have put on this list have been dismissed without any serious
> consideration, and I don't see any point wasting further time unless
> they will be considered respectfully.

I don't remember any dismissal of any use case without an argument.  I think
for your examples there may have been some misunderstanding about what a
parent and a child was, though.  I'll have a look at it and hopefully write a
reply about it.

> Legitimate disagreement is acceptable. Disrespectful dismissal is not.

I very much agree.

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